resolve: Disambiguate a subset of conflicts "macro_rules" vs "macro name in module" #54605
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
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
cc @rust-lang/lang |
petrochenkov
added
the
beta-nominated
This was referenced Sep 27, 2018
|
This all looks and sounds good to me, thanks @petrochenkov! r=me with some tests |
petrochenkov
added
S-waiting-on-author
pietroalbini
added
the
T-compiler
|
@bors r=alexcrichton |
|
📌 Commit d8887bf61a626f39e26302902128b6915517c99a has been approved by |
bors
added
S-waiting-on-bors
|
Argh, asserts are firing. Will fix tomorrow. |
bors
added
S-waiting-on-author
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
…ons in some cases
|
@bors r=alexcrichton |
|
📌 Commit 078fc52 has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Oct 3, 2018
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)
|
💔 Test failed - status-travis |
bors
added
S-waiting-on-review
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
The relevant link error message: |
kennytm
added
S-waiting-on-author
|
Spurious? I don't this emscripten-specific linking error has anything to do with my PR. |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Oct 3, 2018
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)
|
☀️ Test successful - status-appveyor, status-travis |
|
discussed at T-compiler meeting. accepting for beta backport. |
pnkfelix
added
the
beta-accepted
pietroalbini
removed
the
beta-nominated
bors
added a commit
that referenced
this pull request
Oct 4, 2018
[beta] Rollup backports Merged and approved: * #54605: resolve: Disambiguate a subset of conflicts "macro_rules" vs "macro name in module" * #54557: incr.comp.: Don't automatically enable -Zshare-generics for incr. comp. builds. * #54759: do not normalize non-scalar constants to a ConstValue::ScalarPair Closes #54759 r? @ghost
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 if macro name may refer to both a
macro_rulesmacro 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_rulesif both themacro_rulesitem and in-module macro name are defined in the same normal (named) module andmacro_rulesis 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
letvariables and items defined in blocks (macro_rulesbehaves like "letat module level" in general).More complex examples with
useandmacro_rulesfrom different modules still report ambiguity errors, even if equivalent examples withletare legal.Fixes #54472 (stable-to-beta regression)