-
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
resolve: Relax one restriction on macro namespace #56573
Conversation
r? @oli-obk (rust_highfive has picked a reviewer for you, use r? to override) |
@bors try |
resolve: Relax one restriction on macro namespace It was assumed to be necessary to resolve multi-segment macro paths reliably, but it's likely that the assumption was incorrect.
☀️ Test successful - status-travis |
@craterbot run start=master#cd48ce1e9a9c0965f01ede2ea1a554eca2c74336 end=try#1e86cd8e8fc3d50d814cefa5dbd42a13b09d4e22 mode=check-only |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
Can you expand on why we are doing this change and why "it's likely that the assumption was incorrect."? |
🎉 Experiment
|
Imports are also resolved early, as macros, but don't have this restriction. * However, one timely reported issue (#56593) shows that we did have problems with imports all this time in the same situation (macro expanded name shadows glob import), so perhaps we need to keep the restriction for macros and additionally apply it imports as well. I'll close this until the situation with #56593 becomes clear. |
The restriction is "macro-expanded macros cannot shadow glob-imported macros during resolution in module", where "in module" means the macro path has module prefix (
module::my_macro!()
, but notmy_macro!()
).This is a special case that was assumed to be necessary to resolve multi-segment macro paths reliably, but it's likely that the assumption was incorrect.