-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Open
Labels
A-resolveArea: Name/path resolution done by `rustc_resolve` specificallyArea: Name/path resolution done by `rustc_resolve` specificallyA-trait-systemArea: Trait systemArea: Trait systemT-langRelevant to the language teamRelevant to the language teamT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Description
Today item import take precedence over glob imports which take precedence over prelude imports. This works for traits:
mod a {
pub trait X {
fn x(&self) { println!("a"); }
}
impl X for () {}
}
mod b {
pub trait X {
fn x(&self) { println!("b"); }
}
impl X for () {}
}
use a::X;
use b::*;
fn main() {
().x(); // Works and prints "a", b/c b is shadowed
}
However, this logic does not work for trait methods. If we rename b::X
to b::Y
, the code fails to compile:
mod a {
pub trait X {
fn x(&self) { println!("a"); }
}
impl X for () {}
}
mod b {
pub trait Y {
fn x(&self) { println!("b"); }
}
impl Y for () {}
}
use a::X;
use b::*;
fn main() {
().x(); // error: multiple `x` found
}
I think this problematic for two reasons:
- it seems inconsistent with how other names work
- it makes adding a trait to prelude in std and other crates a breaking change (see Tracking issue for the 2018 edition’s prelude #51418)
Could we perhaps fix it?
r? @rust-lang/lang
Metadata
Metadata
Assignees
Labels
A-resolveArea: Name/path resolution done by `rustc_resolve` specificallyArea: Name/path resolution done by `rustc_resolve` specificallyA-trait-systemArea: Trait systemArea: Trait systemT-langRelevant to the language teamRelevant to the language teamT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.