-
Notifications
You must be signed in to change notification settings - Fork 13.3k
macros: hygienize use of core
/std
in builtin macros
#46550
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
Conversation
@bors: r+ |
📌 Commit 6f8df8c has been approved by |
⌛ Testing commit 6f8df8c with merge f40e75d38b2de81b9cf034d4f8c64b003ae79361... |
💔 Test failed - status-travis |
6f8df8c
to
d4b7c2c
Compare
@bors r=nrc |
📌 Commit d4b7c2c has been approved by |
⌛ Testing commit d4b7c2c963266d22f6661fb0febceba20621788b with merge 504235de64dce04ff0d720bec0a16f2dc8bb55f8... |
💔 Test failed - status-travis |
The pretty tests produced identifier paths without its crate (
|
d4b7c2c
to
3bade7f
Compare
@bors r=nrc |
📌 Commit 3bade7f has been approved by |
This feels like it's ignoring a bit too many tests, which means that pretty might be very broken. If this is not fixed quickly it could remain broken for quite some time. @bors r- |
Ok, was going to write fix in separate PR -- I'll make sure to avoid regressing these tests then though. |
Pretty is already "broken" for I can fix the |
Sure I know about that, I just don't want to let all the pretty tests bitrot before that gets fixed |
3bade7f
to
57f373f
Compare
57f373f
to
85d19b3
Compare
I avoided regressing any pretty tests by printing @bors r=nrc |
📌 Commit 85d19b3 has been approved by |
macros: hygienize use of `core`/`std` in builtin macros Today, if a builtin macro wants to access an item from `core` or `std` (depending `#![no_std]`), it generates `::core::path::to::item` or `::std::path::to::item` respectively (c.f. `fn std_path()` in `libsyntax/ext/base.rs`). This PR refactors the builtin macros to instead always emit `$crate::path::to::item` here. That is, the def site of builtin macros is taken to be in `extern crate core;` or `extern crate std;`. Since builtin macros are macros 1.0 (i.e. mostly unhygienic), changing the def site can only effect the resolution of `$crate`. r? @nrc
☀️ Test successful - status-appveyor, status-travis |
Today, if a builtin macro wants to access an item from
core
orstd
(depending#![no_std]
), it generates::core::path::to::item
or::std::path::to::item
respectively (c.f.fn std_path()
inlibsyntax/ext/base.rs
).This PR refactors the builtin macros to instead always emit
$crate::path::to::item
here. That is, the def site of builtin macros is taken to be inextern crate core;
orextern crate std;
. Since builtin macros are macros 1.0 (i.e. mostly unhygienic), changing the def site can only effect the resolution of$crate
.r? @nrc