-
Notifications
You must be signed in to change notification settings - Fork 13.4k
[1.30 beta] Ambiguous macro names #54472
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Only the |
All the ambiguities are legitimate, sorry :( I think we may be able to reliably disambiguate some of these in the future, but that's not something that can be backported to beta. One low-hanging fruit is treating glob imports from other crates as single imports for the purposes of restricted shadowing. |
It actually won't help with regressions here, I've misinterpreted the error messages. The ambiguities in listed crates are " fn main() {
let x = || 0;
println!("{:?}", x());
{
println!("{:?}", x());
fn x() -> i32 { 1 }
println!("{:?}", x());
let x = || 2;
println!("{:?}", x());
}
println!("{:?}", x());
}
---
0
1
1
2
0 |
@petrochenkov should we also warn when resolving in favour of |
I don't think so? In all the regressed cases the It's not something to-be-deprecated/hacky either - I planned to implement the scoping rules from #54472 (comment) eventually anyway since it's kinda "natural" expected behavior for |
Minimized reproduction for use std::*;
fn main() {
macro_rules! try { ($expr:expr) => () }
try!(0);
} |
#54605 is updated with a fix for the remaining regressions. |
resolve: Disambiguate a subset of conflicts "macro_rules" vs "macro name in module" Currently if macro name may refer to both a `macro_rules` macro definition and a macro defined/imported into module we conservatively report an ambiguity error. Unfortunately, these errors became a source of regressions when macro modularization was enabled - see issue #54472. This PR disambiguates such conflicts in favor of `macro_rules` if both the `macro_rules` item and in-module macro name are defined in the same normal (named) module and `macro_rules` is closer in scope to the point of use (see the tests for examples). This is a subset of more general approach described in #54472 (comment). The subset is enough to fix all the regressions from #54472, but it can be extended to apply to all "macro_rules" vs "macro name in module" conflicts in the future. To give an analogy, this is equivalent to scoping rules for `let` variables and items defined in blocks (`macro_rules` behaves like "`let` at module level" in general). ```rust { // beginning of the block use xxx::m; // (1) // Starting from the beginning of the block and until here m!() refers to (1) macro_rules! m { ... } // (2) // Starting from here and until the end of the block m!() refers to (2) } // end of the block ``` More complex examples with `use` and `macro_rules` from different modules still report ambiguity errors, even if equivalent examples with `let` are legal. Fixes #54472 (stable-to-beta regression)
resolve: Disambiguate a subset of conflicts "macro_rules" vs "macro name in module" Currently if macro name may refer to both a `macro_rules` macro definition and a macro defined/imported into module we conservatively report an ambiguity error. Unfortunately, these errors became a source of regressions when macro modularization was enabled - see issue #54472. This PR disambiguates such conflicts in favor of `macro_rules` if both the `macro_rules` item and in-module macro name are defined in the same normal (named) module and `macro_rules` is closer in scope to the point of use (see the tests for examples). This is a subset of more general approach described in #54472 (comment). The subset is enough to fix all the regressions from #54472, but it can be extended to apply to all "macro_rules" vs "macro name in module" conflicts in the future. To give an analogy, this is equivalent to scoping rules for `let` variables and items defined in blocks (`macro_rules` behaves like "`let` at module level" in general). ```rust { // beginning of the block use xxx::m; // (1) // Starting from the beginning of the block and until here m!() refers to (1) macro_rules! m { ... } // (2) // Starting from here and until the end of the block m!() refers to (2) } // end of the block ``` More complex examples with `use` and `macro_rules` from different modules still report ambiguity errors, even if equivalent examples with `let` are legal. Fixes #54472 (stable-to-beta regression)
Some crates in 1.30 beta are failing with ambiguous macro names errors:
0.1.4
regressed from stable to beta (build log) cc @ipetkov0.0.8
regressed from stable to beta (build log) cc @ezragoss3.1.0
regressed from stable to beta (build log) cc @darrenldl0.3.0
regressed from stable to beta (build log) cc @durch0.3.0
regressed from stable to beta (build log) cc @sfacklercc @petrochenkov
The text was updated successfully, but these errors were encountered: