-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Explicitly export core and std macros #139493
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
base: master
Are you sure you want to change the base?
Explicitly export core and std macros #139493
Conversation
r? @ChrisDenton rustbot has assigned @ChrisDenton. Use |
r? @Amanieu |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@Amanieu the tidy issue highlights an annoying and unforeseen side-effect of this change. The fn xx(i: vec::IntoIter<i32>) {
let _ = i.as_slice();
}
fn main() {} that currently doesn't compile on stable would now compile. Initially I thought this would cause name collisions if users define their own |
There's an issue for this change - #53977. |
@Voultapher, avoiding the vec module re-export can be done like this: #[macro_export]
macro_rules! myvec {
() => {};
}
pub mod myvec {
pub struct Vec;
}
pub mod prelude {
// Bad: re-exports both macro and type namespace
// pub use crate::myvec;
mod vec_macro_only {
#[allow(hidden_glob_reexports)]
mod myvec {}
pub use crate::*;
}
pub use self::vec_macro_only::myvec;
}
fn main() {
prelude::myvec!();
let _: prelude::myvec::Vec; // error
} |
|
This comment has been minimized.
This comment has been minimized.
@Voultapher Based on the CI failure I think that a try build would fail now. |
Ok, I'll try to get the CI passing first. |
@petrochenkov I went through all macros and searched the docs and |
This comment has been minimized.
This comment has been minimized.
@Amanieu this program previously worked: use std::*;
fn main() {
panic!("panic works")
} and now runs into:
I don't see how we can resolve that without changing language import rules and or special casing the prelude import. |
@petrochenkov Do you have any ideas about that? |
Could you add a test making sure that the modules |
The ambiguity wouldn't happen if it was the same panic in std root and in the stdlib prelude. Previously |
@@ -387,34 +387,6 @@ LL | impl <T = impl Debug> T {} | |||
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! | |||
= note: for more information, see issue #36887 <https://github.com/rust-lang/rust/issues/36887> | |||
|
|||
error[E0283]: type annotations needed | |||
--> $DIR/where-allowed.rs:46:57 |
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.
I'm not sure why this error has disappeared.
Looks like it's still reported if the erroneous case is isolated from other errors, but I'm not sure how the prelude changes could cause something like this?
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.
I noticed the same with isolated reproduction. My guess is it's some subtle compiler bug that requires the surrounding context. My gut feeling is, since it involves nightly APIs and only changes error messages this isn't a blocker for shipping.
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.
I think this needs to be debugged, the errors shouldn't just disappear from unrelated changes.
In the worst case these test cases need to be moved to a separate test file so their errors reproduce as previously.
…r-errors resolve: Tweak `private_macro_use` lint to be compatible with upcoming macro prelude changes Unblocks rust-lang#139493. Zulip thread requesting help - [#t-compiler/help > Help requested for effects of rust-lang#139493](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Help.20requested.20for.20effects.20of.20.23139493/with/514653911). This PR by itself shouldn't cause any observable changes, its only observable effect is that the prelude changes from rust-lang#139493 will no longer cause regressions in tests like `tests/ui/imports/issue-119369.rs` or `tests/ui/extern/issue-80074.rs`. This is achieved by moving the "is this thing in stdlib prelude" check from an early point (`fn process_macro_use_imports`) to a later point (`fn record_use_inner`), at which the stdlib prelude is already populated and can be inspected. (The `is_builtin_macro` check is subsumed by the stdlib prelude check, all built-in macros go through the stdlib prelude anyway.)
…r-errors resolve: Tweak `private_macro_use` lint to be compatible with upcoming macro prelude changes Unblocks rust-lang#139493. Zulip thread requesting help - [#t-compiler/help > Help requested for effects of rust-lang#139493](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Help.20requested.20for.20effects.20of.20.23139493/with/514653911). This PR by itself shouldn't cause any observable changes, its only observable effect is that the prelude changes from rust-lang#139493 will no longer cause regressions in tests like `tests/ui/imports/issue-119369.rs` or `tests/ui/extern/issue-80074.rs`. This is achieved by moving the "is this thing in stdlib prelude" check from an early point (`fn process_macro_use_imports`) to a later point (`fn record_use_inner`), at which the stdlib prelude is already populated and can be inspected. (The `is_builtin_macro` check is subsumed by the stdlib prelude check, all built-in macros go through the stdlib prelude anyway.)
…r-errors resolve: Tweak `private_macro_use` lint to be compatible with upcoming macro prelude changes Unblocks rust-lang#139493. Zulip thread requesting help - [#t-compiler/help > Help requested for effects of rust-lang#139493](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Help.20requested.20for.20effects.20of.20.23139493/with/514653911). This PR by itself shouldn't cause any observable changes, its only observable effect is that the prelude changes from rust-lang#139493 will no longer cause regressions in tests like `tests/ui/imports/issue-119369.rs` or `tests/ui/extern/issue-80074.rs`. This is achieved by moving the "is this thing in stdlib prelude" check from an early point (`fn process_macro_use_imports`) to a later point (`fn record_use_inner`), at which the stdlib prelude is already populated and can be inspected. (The `is_builtin_macro` check is subsumed by the stdlib prelude check, all built-in macros go through the stdlib prelude anyway.)
…r-errors resolve: Tweak `private_macro_use` lint to be compatible with upcoming macro prelude changes Unblocks rust-lang#139493. Zulip thread requesting help - [#t-compiler/help > Help requested for effects of rust-lang#139493](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Help.20requested.20for.20effects.20of.20.23139493/with/514653911). This PR by itself shouldn't cause any observable changes, its only observable effect is that the prelude changes from rust-lang#139493 will no longer cause regressions in tests like `tests/ui/imports/issue-119369.rs` or `tests/ui/extern/issue-80074.rs`. This is achieved by moving the "is this thing in stdlib prelude" check from an early point (`fn process_macro_use_imports`) to a later point (`fn record_use_inner`), at which the stdlib prelude is already populated and can be inspected. (The `is_builtin_macro` check is subsumed by the stdlib prelude check, all built-in macros go through the stdlib prelude anyway.)
Rollup merge of #141934 - petrochenkov:privmacuse, r=compiler-errors resolve: Tweak `private_macro_use` lint to be compatible with upcoming macro prelude changes Unblocks #139493. Zulip thread requesting help - [#t-compiler/help > Help requested for effects of #139493](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Help.20requested.20for.20effects.20of.20.23139493/with/514653911). This PR by itself shouldn't cause any observable changes, its only observable effect is that the prelude changes from #139493 will no longer cause regressions in tests like `tests/ui/imports/issue-119369.rs` or `tests/ui/extern/issue-80074.rs`. This is achieved by moving the "is this thing in stdlib prelude" check from an early point (`fn process_macro_use_imports`) to a later point (`fn record_use_inner`), at which the stdlib prelude is already populated and can be inspected. (The `is_builtin_macro` check is subsumed by the stdlib prelude check, all built-in macros go through the stdlib prelude anyway.)
Reminder, once the PR becomes ready for a review, use |
I'll try to get to it next week. |
Currently all core and std macros are automatically added to the prelude via #[macro_use]. However a situation arose where we want to add a new macro `assert_matches` but don't want to pull it into the standard prelude for compatibility reasons. By explicitly exporting the macros found in the core and std crates we get to decide on a per macro basis and can later add them via the rust_20xx preludes.
87be0d7
to
46800d5
Compare
#![feature(custom_inner_attributes)]
#![rustfmt::skip]
use std::fmt::Debug;
fn in_parameters(_: impl Debug) { todo!() }
fn main() {}
EDIT: This is likely a red herring for another issue. Ignore it for now. |
The job Click to see the possible cause of the failure (guessed by this bot)
|
☔ The latest upstream changes (presumably #143057) made this pull request unmergeable. Please resolve the merge conflicts. |
Currently all core and std macros are automatically added to the prelude via #[macro_use]. However a situation arose where we want to add a new macro
assert_matches
but don't want to pull it into the standard prelude for compatibility reasons. By explicitly exporting the macros found in the core and std crates we get to decide on a per macro basis and can later add them via the rust_20xx preludes.Closes #53977
Unlocks #137487