You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Auto merge of #54605 - petrochenkov:mambig, r=alexcrichton
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)
0 commit comments