Uh oh!
There was an error while loading. Please reload this page.
macros: hygienize use of core/std in builtin macros - #46550
Conversation
nrc
commented
Dec 8, 2017
@bors: r+ |
bors
commented
Dec 8, 2017
📌 Commit 6f8df8c has been approved by |
bors
commented
Dec 8, 2017
⌛ Testing commit 6f8df8c with merge f40e75d38b2de81b9cf034d4f8c64b003ae79361... |
bors
commented
Dec 8, 2017
💔 Test failed - status-travis |
6f8df8c to
d4b7c2cComparejseyfried
commented
Dec 9, 2017
@bors r=nrc |
bors
commented
Dec 9, 2017
📌 Commit d4b7c2c has been approved by |
bors
commented
Dec 9, 2017
⌛ Testing commit d4b7c2c963266d22f6661fb0febceba20621788b with merge 504235de64dce04ff0d720bec0a16f2dc8bb55f8... |
bors
commented
Dec 9, 2017
💔 Test failed - status-travis |
kennytm
commented
Dec 9, 2017
The pretty tests produced identifier paths without its crate ( Details |
d4b7c2c to
3bade7fComparejseyfried
commented
Dec 11, 2017
@bors r=nrc |
bors
commented
Dec 11, 2017
📌 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 |
arielb1
commented
Dec 12, 2017
Sure I know about that, I just don't want to let all the pretty tests bitrot before that gets fixed |
3bade7f to
57f373fCompare57f373f to
85d19b3CompareI avoided regressing any pretty tests by printing @bors r=nrc |
bors
commented
Dec 13, 2017
📌 Commit 85d19b3 has been approved by |
kennytm
commented
Dec 13, 2017
bors
commented
Dec 13, 2017
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
bors
commented
Dec 13, 2017
☀️ Test successful - status-appveyor, status-travis |
Today, if a builtin macro wants to access an item from
coreorstd(depending#![no_std]), it generates::core::path::to::itemor::std::path::to::itemrespectively (c.f.fn std_path()inlibsyntax/ext/base.rs).This PR refactors the builtin macros to instead always emit
$crate::path::to::itemhere. 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