Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

std: Enable usage of thread_local! through imports #55597

Merged
merged 1 commit into from
Nov 6, 2018

Conversation

alexcrichton
Copy link
Member

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.

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.
@rust-highfive
Copy link
Collaborator

r? @KodrAus

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 1, 2018
@KodrAus
Copy link
Contributor

KodrAus commented Nov 1, 2018

@bors r+

@bors
Copy link
Contributor

bors commented Nov 1, 2018

📌 Commit ff5226c has been approved by KodrAus

@bors 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 Nov 1, 2018
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)
@bors
Copy link
Contributor

bors commented Nov 6, 2018

⌛ Testing commit ff5226c with merge f90aab7...

@bors bors merged commit ff5226c into rust-lang:master Nov 6, 2018
@alexcrichton alexcrichton deleted the thread-local-inner branch November 26, 2018 04:27
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
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants