Fix name resolution in lexical scopes #32141
Conversation
|
Can this cause silent changes to existing code (at least add an rpass test): mod Bad {
pub fn default<T>() -> T where T: Default + ::std::ops::Not<Output=T> {
!T::default()
}
}
fn foo<Bad>() -> Bad where Bad: Default + ::std::ops::Not<Output=Bad> {
Bad::default()
}
fn main() {
println!("{}", foo::<i32>());
} |
|
@arielb1 As your example demonstrates, this can cause silent changes to existing code, but only if
which seems highly unlikely to occur in practice. I believe the current test is sufficient to ensure that type parameters properly shadow items -- it would be virtually impossible for code that passes the current test to fail a corresponding rpass test by accident. |
|
Looks nice. I don't quite get what's going on with the refactoring of |
|
I commented
Now that After checking that allowing type parameters and local variables where they used to be excluded would make no difference (modulo diagnostics), I refactored away this argument (treating it as always true). |
jseyfried
force-pushed
the
fix_resolution_in_lexical_scopes
branch
from
b190e56 to
f55908b
Compare
|
📌 Commit f55908b has been approved by |
jseyfried
force-pushed
the
fix_resolution_in_lexical_scopes
branch
2 times, most recently
from
2902c8b to
e926f28
Compare
|
@bors r=nikomatsakis |
|
📌 Commit e926f28 has been approved by |
…_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
|
⌛ Testing commit e926f28 with merge 63906b6... |
|
💔 Test failed - auto-win-gnu-32-opt |
|
@bors: retry On Sat, Mar 12, 2016 at 7:31 AM, bors [email protected] wrote:
|
…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
Currently,
resolve_item_in_lexical_scopedoes 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,
This PR changes
resolve_item_in_lexical_scopeso 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