std tests: use __OsLocalKeyInner from realstd by RalfJung · Pull Request #106638 · rust-lang/rust

RalfJung · 2023-01-09T15:43:19Z

This is basically the same as #100201, but for __OsLocalKeyInner:

Some std tests are failing in Miri on Windows because this static is getting duplicated, and Miri does not handle that properly -- Miri does not support this magic .CRT$XLB linker section, but instead just looks up this particular hard-coded static in the standard library. This PR lets the test suite use the std static instead of having its own copy.

Fixes rust-lang/miri#2754
r? @thomcc

rustbot · 2023-01-09T15:43:26Z

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

Stabilizing library features
Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
Changing public documentation in ways that create new stability guarantees
Changing observable runtime behavior of library APIs

thomcc

Sorry for the delay, been swamped with work.

This seems fine to me.

thomcc · 2023-01-12T01:07:59Z

@bors r+ rollup

bors · 2023-01-12T01:08:01Z

📌 Commit ad79b20 has been approved by thomcc

It is now in the queue for this repository.

std tests: use __OsLocalKeyInner from realstd This is basically the same as rust-lang#100201, but for __OsLocalKeyInner: Some std tests are failing in Miri on Windows because [this static](https://github.com/rust-lang/rust/blob/a377893da2cd7124e5a18c7116cbb70e16dd5541/library/std/src/sys/windows/thread_local_key.rs#L234-L239) is getting duplicated, and Miri does not handle that properly -- Miri does not support this magic `.CRT$XLB` linker section, but instead just looks up this particular hard-coded static in the standard library. This PR lets the test suite use the std static instead of having its own copy. Fixes rust-lang/miri#2754 r? ``@thomcc``

…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#106167 (Fix invalid syntax and incomplete suggestion in impl Trait parameter type suggestions for E0311) - rust-lang#106309 (Prefer non-`[type error]` candidates during selection) - rust-lang#106532 (Allow codegen to unsize `dyn*` to `dyn`) - rust-lang#106596 (Hide more of long types in E0271) - rust-lang#106638 (std tests: use __OsLocalKeyInner from realstd) - rust-lang#106676 (Test that we cannot use trait impl methods arguments as defining uses) - rust-lang#106702 (Conserve cause of `ImplDerivedObligation` in E0599) - rust-lang#106732 (rustc_llvm: replace llvm::makeArrayRef with ArrayRef constructors.) - rust-lang#106733 (Revert "warn newer available version of the x tool") - rust-lang#106748 (Clean up `OnUnimplementedFormatString::verify`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

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`````

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/rust#100201 and rust-lang/rust#106638, which got reverted by rust-lang/rust#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``````

std tests: use __OsLocalKeyInner from realstd

ad79b20

rustbot assigned thomcc Jan 9, 2023

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 9, 2023

This was referenced Jan 9, 2023

dtors_in_dtors_in_dtors test fails on 32bit Windows targets rust-lang/miri#2754

Closed

run some std tests on Windows rust-lang/miri-test-libstd#13

Merged

thomcc approved these changes Jan 12, 2023

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 12, 2023

matthiaskrgr mentioned this pull request Jan 12, 2023

Rollup of 10 pull requests #106757

Merged

Dylan-DPC mentioned this pull request Jan 12, 2023

Rollup of 7 pull requests #106758

Closed

bors merged commit db8301b into rust-lang:master Jan 12, 2023

rustbot added this to the 1.68.0 milestone Jan 12, 2023

RalfJung deleted the realstd branch January 31, 2023 11:06

This was referenced Apr 28, 2023

Restructure and rename std thread_local internals to make it less of a maze #110861

Merged

avoid duplicating TLS state between test std and realstd #110946

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

std tests: use __OsLocalKeyInner from realstd#106638

std tests: use __OsLocalKeyInner from realstd#106638
bors merged 1 commit intorust-lang:masterfrom
RalfJung:realstd

RalfJung commented Jan 9, 2023 •

edited

Loading

Uh oh!

rustbot commented Jan 9, 2023

Uh oh!

thomcc left a comment

Uh oh!

thomcc commented Jan 12, 2023

Uh oh!

bors commented Jan 12, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

RalfJung commented Jan 9, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jan 9, 2023

Uh oh!

thomcc left a comment

Choose a reason for hiding this comment

Uh oh!

thomcc commented Jan 12, 2023

Uh oh!

bors commented Jan 12, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

RalfJung commented Jan 9, 2023 •

edited

Loading