Skip to content
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

Ambiguous item error fails to trigger when use is declared before the source #112713

Closed
P1n3appl3 opened this issue Jun 16, 2023 · 0 comments · Fixed by #113099
Closed

Ambiguous item error fails to trigger when use is declared before the source #112713

P1n3appl3 opened this issue Jun 16, 2023 · 0 comments · Fixed by #113099
Labels
A-local-reexports Area: Documentation that has been locally re-exported (i.e., non-cross-crate) A-resolve Area: Path resolution C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@P1n3appl3
Copy link
Contributor

With the following code:

pub fn foo() -> u32 {
    use sub::*;
    C
}

mod sub {
    mod mod1 { pub const C: u32 = 1; }
    mod mod2 { pub const C: u32 = 2; }

    pub use mod1::*;
    pub use mod2::*;
}

We expected to see this compiler error.

Instead, the compiler accepts it and foo() returns 1. We found that if you move foo below sub, you do get the expected error. @ComputerDruid and I took a while to repro this, because we assumed that the order in which you define functions/modules shouldn't change the semantics. It appears that glob re-exports are also necessary for this behavior to occur. If you change it to:

    pub use mod1::*;
    pub use mod2::C;

The explicit one will shadow the glob regardless of where foo is defined, and if you make both explicit, it'll trigger this error.

You can see the difference if you uncomment the bottom function in this playground link. Even changing the import within foo to use sub::C will make it trigger the expected ambiguous item error, so both of the re-exports and the import have to be globs to see the weird behavior.

This may be a separate issue, but in the accepted code if you swap the order of the glob re-exports in sub, foo() will return 2, suggesting that whichever one is re-exported first "wins".

rustc --version --verbose:

rustc 1.70.0 (90c541806 2023-05-31)

(same behavior on nightly)

@P1n3appl3 P1n3appl3 added the C-bug Category: This is a bug. label Jun 16, 2023
@tmandry tmandry added A-resolve Area: Path resolution T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. I-prioritize Issue: Indicates that prioritization has been requested for this issue. A-local-reexports Area: Documentation that has been locally re-exported (i.e., non-cross-crate) labels Jun 16, 2023
@bors bors closed this as completed in 2dc6610 Jul 29, 2023
@apiraino apiraino removed the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Aug 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-local-reexports Area: Documentation that has been locally re-exported (i.e., non-cross-crate) A-resolve Area: Path resolution C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
3 participants