Explicitly export core and std macros #139493
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
|
r? @ChrisDenton rustbot has assigned @ChrisDenton. Use |
rustbot
added
S-waiting-on-review
|
r? @Amanieu |
This comment has been minimized.
This comment has been minimized.
Amanieu
reviewed
Apr 7, 2025
|
|
||
| use super::*; | ||
| // Explicit import to avoid macro namespace collision. | ||
| use super::{arena, client, DecodeMut, Encode, fxhash, Mark, Marked, Reader, server, Unmark, Writer}; |
There was a problem hiding this comment.
What collision is this? Is this something that user code is likely to encounter?
There was a problem hiding this comment.
Here is the error that I get when not making this change:
error[E0659]: `panic` is ambiguous
--> library/proc_macro/src/bridge/symbol.rs:41:17
|
41 | panic!("`{}` cannot be a raw identifier", string);
| ^^^^^ ambiguous name
|
= note: ambiguous because of a conflict between a name from a glob import and an outer scope during import or macro resolution
note: `panic` could refer to the macro imported here
--> library/proc_macro/src/bridge/symbol.rs:19:5
|
19 | use super::*;
| ^^^^^^^^
= help: consider adding an explicit import of `panic` to disambiguate
= help: or use `self::panic` to refer to this macro unambiguously
note: `panic` could also refer to the macro defined here
--> /rust/library/std/src/prelude/mod.rs:157:13
|
157 | pub use super::v1::*;
| ^^^^^^^^^
My reasoning is a follows, this special proc macro is built together with std which gives access to std via super, causing the import ambiguity. I don't think this is an issue for user code since normal crates can't access std via super - I checked - and I assume normal proc macros can't either, but I'm no expert in that area.
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 |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
@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? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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_matchesbut 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.Unlocks #137487