Hygienize macros in the standard library #61629
Conversation
rust-highfive
added
the
S-waiting-on-review
|
@bors try |
|
⌛ Trying commit b5e00d8122499c60159d3e0e54017ce8bbc35cc1 with merge e212b7d492c96d3837691ba29d32d5f468933fb8... |
|
☀️ Try build successful - checks-travis |
|
@craterbot run |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
@petrochenkov wait, does this need to be a |
|
@pietroalbini |
|
Can this replace |
|
@matklad To call built-in macros reliably with |
|
🎉 Experiment
|
craterbot
added
S-waiting-on-review
|
This is looking good to me, and the crate run there looks all largely spurious to me, so I think we could probably go ahead and land this? |
|
Rebased/squashed. Recursive calls from |
|
@bors: r+ |
|
📌 Commit eb09daa has been approved by |
bors
added
S-waiting-on-bors
|
@bors rollup |
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
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
Rollup of 9 pull requests Successful merges: - #60376 (Stabilize Option::xor) - #61398 (Stabilize copy_within) - #61629 (Hygienize macros in the standard library) - #61675 (Include frame pointer for bare metal RISC-V targets) - #61750 (Fix x.py install) - #61761 (Add an alias for x86_64-sun-solaris target tuple) - #61762 (rustbuild: fix libtest_stamp) - #61763 (ci: fix ci stats upload condition) - #61776 (Fix typos in error_codes) Failed merges: r? @ghost
pnkfelix
added
beta-nominated
|
discussed at T-compiler meeting. Accepting for backport to beta. |
pnkfelix
added
the
beta-accepted
pietroalbini
removed
the
beta-nominated
[beta] Rollup backports Rolled up: * [beta] Comment out dev key #61700 Cherry picked: * Dont ICE on an attempt to use GAT without feature gate #61118 * Fix cfg(test) build for x86_64-fortanix-unknown-sgx #61503 * Handle index out of bound errors during const eval without panic #61598 * Hygienize macros in the standard library #61629 * Fix ICE involving mut references #61947 * rustc_typeck: correctly compute `Substs` for `Res::SelfCtor`. #61896 * Revert "Set test flag when rustdoc is running with --test option" #61199 * create a "provisional cache" to restore performance in the case of cycles #61754 r? @ghost
Hygienize use of built-in macros in the standard library Same as rust-lang#61629, but for built-in macros. Closes rust-lang#48781 r? @alexcrichton
Same as #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::panicorcore::panicdepending onno_stdsettings.EDIT: After some thought, recursive calls to
panicfrompanicitself probably do want to use$crate(UPDATE: done).Calling
std::panicfrom macros defined in std and "whateverpanicis in scope" from macros defined in libcore is probably even worse than always calling "whateverpanicis 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::panicorcore::panicusing compiler magic.Then standard library macros could delegate to this built-in macro.
The macro could be named
panictoo, that would fix #61567.(This PR doesn't do that.)
cc #56389
cc #61567
Fixes #61699
r? @alexcrichton