avoid duplicating TLS state between test std and realstd #110946
Conversation
rustbot
added
S-waiting-on-review
|
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
|
(tbh it would be nice if the "magic linker section" bit was implemented with the help of a little bit of compiler magic as it is hacky even in std, but I digress) |
|
If it's only for miri, can this be |
|
Oh, this is only for the situation where miri is used to test std itself. I suppose we don't run that in CI. |
|
Indeed we only run that in miri-test-libsts.
We could make this 'all(test, miri)' if you prefer. I used cfg(test) since realstd is usually used to avoid duplicate global state and having 2 rust-managed lists of tls dtors seems like that kind of duplicated global state.
|
Yeah that's true. It might make sense to run the regular std tests with 'duplicated' global state on purpose, because almost the same thing would happen when (dynamically) loading a Rust library into a Rust binary if both the library and the binary have their own copy of std. But I don't think we support that situation well yet, so maybe that's something for later. @bors r+ |
bors
added
S-waiting-on-bors
Either both need to dynamically link the same libstd or they need to communicate only through |
|
For panics and the panic counter, sure. But for thread_local destructors, it should work "just fine" to keep two independent lists, I think. (Note that no tests failed other than miri.) |
avoid duplicating TLS state between test std and realstd This basically re-lands rust-lang#100201 and rust-lang#106638, which got reverted by rust-lang#110861. This works around 2 Miri limitations: - Miri doesn't support the magic linker section that our Windows TLS support relies on, and instead knows where in std to find the symbol that stores the thread callback. - For macOS, Miri only supports at most one destructor to be registered per thread. The 2nd would not be very hard to fix (though the intended destructor order is unclear); the first would be a lot of work to fix. Neither of these is a problem for regular Rust code, but in the std test suite we have essentially 2 copies of the std code and then these both become issues. To avoid that we have the std test crate import the TLS code from the real std instead of having its own copy. r? `@m-ou-se`
avoid duplicating TLS state between test std and realstd This basically re-lands rust-lang#100201 and rust-lang#106638, which got reverted by rust-lang#110861. This works around 2 Miri limitations: - Miri doesn't support the magic linker section that our Windows TLS support relies on, and instead knows where in std to find the symbol that stores the thread callback. - For macOS, Miri only supports at most one destructor to be registered per thread. The 2nd would not be very hard to fix (though the intended destructor order is unclear); the first would be a lot of work to fix. Neither of these is a problem for regular Rust code, but in the std test suite we have essentially 2 copies of the std code and then these both become issues. To avoid that we have the std test crate import the TLS code from the real std instead of having its own copy. r? ``@m-ou-se``
avoid duplicating TLS state between test std and realstd This basically re-lands rust-lang#100201 and rust-lang#106638, which got reverted by rust-lang#110861. This works around 2 Miri limitations: - Miri doesn't support the magic linker section that our Windows TLS support relies on, and instead knows where in std to find the symbol that stores the thread callback. - For macOS, Miri only supports at most one destructor to be registered per thread. The 2nd would not be very hard to fix (though the intended destructor order is unclear); the first would be a lot of work to fix. Neither of these is a problem for regular Rust code, but in the std test suite we have essentially 2 copies of the std code and then these both become issues. To avoid that we have the std test crate import the TLS code from the real std instead of having its own copy. r? ```@m-ou-se```
avoid duplicating TLS state between test std and realstd This basically re-lands rust-lang#100201 and rust-lang#106638, which got reverted by rust-lang#110861. This works around 2 Miri limitations: - Miri doesn't support the magic linker section that our Windows TLS support relies on, and instead knows where in std to find the symbol that stores the thread callback. - For macOS, Miri only supports at most one destructor to be registered per thread. The 2nd would not be very hard to fix (though the intended destructor order is unclear); the first would be a lot of work to fix. Neither of these is a problem for regular Rust code, but in the std test suite we have essentially 2 copies of the std code and then these both become issues. To avoid that we have the std test crate import the TLS code from the real std instead of having its own copy. r? ````@m-ou-se````
avoid duplicating TLS state between test std and realstd This basically re-lands rust-lang#100201 and rust-lang#106638, which got reverted by rust-lang#110861. This works around 2 Miri limitations: - Miri doesn't support the magic linker section that our Windows TLS support relies on, and instead knows where in std to find the symbol that stores the thread callback. - For macOS, Miri only supports at most one destructor to be registered per thread. The 2nd would not be very hard to fix (though the intended destructor order is unclear); the first would be a lot of work to fix. Neither of these is a problem for regular Rust code, but in the std test suite we have essentially 2 copies of the std code and then these both become issues. To avoid that we have the std test crate import the TLS code from the real std instead of having its own copy. r? `````@m-ou-se`````
Rollup of 8 pull requests Successful merges: - rust-lang#110946 (avoid duplicating TLS state between test std and realstd) - rust-lang#110954 (Reject borrows of projections in ConstProp.) - rust-lang#111052 (Fix problems with backtraces in two ui tests.) - rust-lang#111132 (cleanup nll generalizer) - rust-lang#111173 (Still more encoder cleanups) - rust-lang#111187 (bootstrap: add llvm-project/runtimes to the sources) - rust-lang#111213 (Fixup "since" dates for `array_tuple_conv` feature) - rust-lang#111223 (Use `free-args` consistently in bootstrap) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This basically re-lands #100201 and #106638, which got reverted by #110861. This works around 2 Miri limitations:
The 2nd would not be very hard to fix (though the intended destructor order is unclear); the first would be a lot of work to fix. Neither of these is a problem for regular Rust code, but in the std test suite we have essentially 2 copies of the std code and then these both become issues. To avoid that we have the std test crate import the TLS code from the real std instead of having its own copy.
r? @m-ou-se