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

Struct constructors can resolve to structs that are shadowed by type parameters #32120

Closed
jseyfried opened this issue Mar 8, 2016 · 2 comments · Fixed by #32141
Closed

Struct constructors can resolve to structs that are shadowed by type parameters #32120

jseyfried opened this issue Mar 8, 2016 · 2 comments · Fixed by #32141

Comments

@jseyfried
Copy link
Contributor

For example,

struct T { i: i32 }
impl T {
    fn new() -> Self { unimplemented!() }
}

fn f<T>() {
    let t = T { i: 0 }; // This use of `T` refers to the struct
    let t = T::new(); // This use of `T` refers to the type parameter (and so is an error)
}
@jseyfried
Copy link
Contributor Author

Also,

mod T {
    pub fn f() { println!("foo"); }
}

trait Bar {
    fn f() { println!("bar"); }
}
impl Bar for () {}

fn f<T: Bar>(t: T) {
    T::f();
}

fn main() {
    f(()) // This prints "foo". If the module `T` is removed, it prints "bar".
}

@arielb1
Copy link
Contributor

arielb1 commented Mar 8, 2016

I think the culprit is that associated item notation/UFCS is shadowed by everything.

Manishearth added a commit to Manishearth/rust that referenced this issue Mar 12, 2016
…_scopes, r=nikomatsakis

Fix name resolution in lexical scopes

Currently, `resolve_item_in_lexical_scope` does not check the "ribs" (type parameters and local variables). This can allow items that should be shadowed by type parameters to be named.

For example,
```rust
struct T { i: i32 }
fn f<T>() {
    let t = T { i: 0 }; // This use of `T` resolves to the struct, not the type parameter
}

mod Foo {
    pub fn f() {}
}
fn g<Foo>() {
    Foo::f(); // This use of `Foo` resolves to the module, not the type parameter
}
```

This PR changes `resolve_item_in_lexical_scope` so that it fails when the item is shadowed by a rib (fixes rust-lang#32120).
This is a [breaking-change], but it looks unlikely to cause breakage in practice.

r? @nikomatsakis
bors added a commit that referenced this issue Mar 13, 2016
…nikomatsakis

Fix name resolution in lexical scopes

Currently, `resolve_item_in_lexical_scope` does not check the "ribs" (type parameters and local variables). This can allow items that should be shadowed by type parameters to be named.

For example,
```rust
struct T { i: i32 }
fn f<T>() {
    let t = T { i: 0 }; // This use of `T` resolves to the struct, not the type parameter
}

mod Foo {
    pub fn f() {}
}
fn g<Foo>() {
    Foo::f(); // This use of `Foo` resolves to the module, not the type parameter
}
```

This PR changes `resolve_item_in_lexical_scope` so that it fails when the item is shadowed by a rib (fixes #32120).
This is a [breaking-change], but it looks unlikely to cause breakage in practice.

r? @nikomatsakis
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants