-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Make #[cfg(bootstrap)] not error in proc macros on later stages #98147
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
Can you please remove the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM as this follows the pre-existing hack, even-trough this is very ugly hack.
As was discovered in rust-lang#93628 (comment) , adding #[cfg(bootstrap)] to a rust-internal proc macro crate would yield an unexpected cfg name error, at least on later stages wher the bootstrap cfg arg wasn't set. rustc already passes arguments to mark bootstrap as expected, however the means of delivery through the RUSTFLAGS env var is unable to reach proc macro crates, as described in the issue linked in the code this commit touches. This wouldn't be an issue for cfg args that get passed through RUSTFLAGS, as they would never become *active* either, so any usage of one of these flags in a proc macro's code would legitimately yield a lint warning. But since dc30258, rust takes extra measures to pass --cfg=bootstrap even in proc macros, by passing it via the wrapper. Thus, we need to send the flags to mark bootstrap as expected also from the wrapper, so that #[cfg(bootstrap)] also works from proc macros. I want to thank Urgau and jplatte for helping me find the cause of this. ❤️
642f3ef
to
471fa05
Compare
cmd.arg("--cfg=bootstrap"); | ||
} | ||
cmd.arg("-Zunstable-options"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still sad about the blanket enable of unstable-options being required, but ultimately it's probably OK.
@bors r+ rollup |
📌 Commit 471fa05 has been approved by |
…askrgr Rollup of 4 pull requests Successful merges: - rust-lang#97757 (Support lint expectations for `--force-warn` lints (RFC 2383)) - rust-lang#98125 (Entry and_modify doc) - rust-lang#98137 (debuginfo: Fix NatVis for Rc and Arc with unsized pointees.) - rust-lang#98147 (Make #[cfg(bootstrap)] not error in proc macros on later stages ) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
As was discovered in #93628 (comment),
adding #[cfg(bootstrap)] to a rust-internal proc macro crate
would yield an unexpected cfg name error, at least on later
stages wher the bootstrap cfg arg wasn't set.
rustc already passes arguments to mark bootstrap as expected,
however the means of delivery through the RUSTFLAGS env var
is unable to reach proc macro crates, as described
in the issue linked in the code this commit touches.
This wouldn't be an issue for cfg args that get passed through
RUSTFLAGS, as they would never become active either, so
any usage of one of these flags in a proc macro's code would
legitimately yield a lint warning. But since dc30258,
rust takes extra measures to pass --cfg=bootstrap even in
proc macros, by passing it via the wrapper. Thus, we need
to send the flags to mark bootstrap as expected also from the
wrapper, so that #[cfg(bootstrap)] also works from proc macros.
I want to thank
Urgau
andjplatte
for helping me find the cause of this. ❤️