std: Enable usage of thread_local! through imports
#55597
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `thread_local!` macro delegated to an internal macro but it didn't do so in a macros-and-the-module-system compatible fashion, meaning if a `#![no_std]` crate imported `std` and tried to use `thread_local!` it would fail due to missing a lookup of an internal macro. This commit switches the macro to instead use `$crate` to invoke other macros, ensuring that it'll work when `thread_local!` is imported alone.
|
r? @KodrAus (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ |
|
📌 Commit ff5226c has been approved by |
bors
added
S-waiting-on-bors
kennytm
added a commit
to kennytm/rust
that referenced
this pull request
Nov 6, 2018
…KodrAus std: Enable usage of `thread_local!` through imports The `thread_local!` macro delegated to an internal macro but it didn't do so in a macros-and-the-module-system compatible fashion, meaning if a `#![no_std]` crate imported `std` and tried to use `thread_local!` it would fail due to missing a lookup of an internal macro. This commit switches the macro to instead use `$crate` to invoke other macros, ensuring that it'll work when `thread_local!` is imported alone.
bors
added a commit
that referenced
this pull request
Nov 6, 2018
Rollup of 11 pull requests Successful merges: - #55490 (resolve: Fix ICE in macro import error recovery) - #55597 (std: Enable usage of `thread_local!` through imports) - #55601 (Fix tracking issue numbers for some unstable features) - #55621 (Add precision for create_dir function) - #55644 (ci: Add Dockerfile for dist-powerpcspe-linux) - #55664 (Make "all possible cases" help message uniform with existing help messages) - #55689 (miri: binary_op_val -> binary_op_imm) - #55694 (Fixes #31076) - #55696 (NLL Diagnostic Review 3: Missing errors for borrows of union fields) - #55700 (Update ui tests with respect to NLL) - #55703 (Update `configure --help` (via configure.py) to reflect decoupling of debug+optimize)
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jun 12, 2019
Hygienize macros in the standard library Same as rust-lang#55597, but for all macros in the standard library. Nested macro calls will now call what they are intended to call rather than whatever is in the closest scope at call site. Technically this is a breaking change, so crater run would probably be useful. --- One exception that is not hygienized is calls to `panic!(...)`. Macros defined in libcore do not want to call `core::panic`. What they really want to call is either `std::panic` or `core::panic` depending on `no_std` settings. EDIT: After some thought, recursive calls to `panic` from `panic` itself probably do want to use `$crate` (UPDATE: done). Calling `std::panic` from macros defined in std and "whatever `panic` is in scope" from macros defined in libcore is probably even worse than always calling "whatever `panic` is in scope", so I kept the existing code. The only way to do the std/core switch correctly that I'm aware of is to define a built-in panic macro that would dispatch to `std::panic` or `core::panic` using compiler magic. Then standard library macros could delegate to this built-in macro. The macro could be named `panic` too, that would fix rust-lang#61567. (This PR doesn't do that.) --- cc rust-lang#56389 cc rust-lang#61567 Fixes rust-lang#61699 r? @alexcrichton
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jun 12, 2019
Hygienize macros in the standard library Same as rust-lang#55597, but for all macros in the standard library. Nested macro calls will now call what they are intended to call rather than whatever is in the closest scope at call site. Technically this is a breaking change, so crater run would probably be useful. --- One exception that is not hygienized is calls to `panic!(...)`. Macros defined in libcore do not want to call `core::panic`. What they really want to call is either `std::panic` or `core::panic` depending on `no_std` settings. EDIT: After some thought, recursive calls to `panic` from `panic` itself probably do want to use `$crate` (UPDATE: done). Calling `std::panic` from macros defined in std and "whatever `panic` is in scope" from macros defined in libcore is probably even worse than always calling "whatever `panic` is in scope", so I kept the existing code. The only way to do the std/core switch correctly that I'm aware of is to define a built-in panic macro that would dispatch to `std::panic` or `core::panic` using compiler magic. Then standard library macros could delegate to this built-in macro. The macro could be named `panic` too, that would fix rust-lang#61567. (This PR doesn't do that.) --- cc rust-lang#56389 cc rust-lang#61567 Fixes rust-lang#61699 r? @alexcrichton
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
thread_local!macro delegated to an internal macro but it didn'tdo so in a macros-and-the-module-system compatible fashion, meaning if a
#![no_std]crate importedstdand tried to usethread_local!itwould fail due to missing a lookup of an internal macro.
This commit switches the macro to instead use
$crateto invoke othermacros, ensuring that it'll work when
thread_local!is imported alone.