Fix name resolution in lexical scopes

[jseyfried]

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,

structT{i:i32}fnf<T>(){let t = T{i:0};// This use of `T` resolves to the struct, not the type parameter}modFoo{pubfnf(){}}fng<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

[jseyfried]

cc @petrochenkov@arielb1

[arielb1]

Can this cause silent changes to existing code (at least add an rpass test):

modBad{pubfndefault<T>() -> TwhereT:Default + ::std::ops::Not<Output=T>{
!T::default()}}fnfoo<Bad>() -> BadwhereBad:Default + ::std::ops::Not<Output=Bad>{Bad::default()}fnmain(){println!("{}", foo::<i32>());}

[jseyfried]

@arielb1 As your example demonstrates, this can cause silent changes to existing code, but only if

• a type parameter shadows a module (violating camel/snake case convention) and
• the first element of a path that currently resolves to the shadowed module could also resolve to the type parameter and everything would still resolve and typecheck,

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.

[nikomatsakis]

Looks nice. I don't quite get what's going on with the refactoring of check_ribs, but I have confidence that it is correct. r=me with a comment (bonus points for adding similar comments to some of the other fns you touched ;)

[jseyfried]

I commented resolve_name_in_lexical_scope.

I don't quite get what's going on with the refactoring of check_ribs

Now that resolve_item_in_lexical_scope also checks the ribs, the only difference between check_ribs=false and check_ribs=true (for all the functions with this argument) was that check_ribs=false excluded type parameters and local variables but check_ribs=true allowed them.

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).

[bors]

📌 Commit f55908b has been approved by jseyfried

[jseyfried]

@bors r=nikomatsakis

[bors]

📌 Commit e926f28 has been approved by nikomatsakis

[bors]

⌛ Testing commit e926f28 with merge 63906b6...

[bors]

💔 Test failed - auto-win-gnu-32-opt

[alexcrichton]

@bors: retry

On Sat, Mar 12, 2016 at 7:31 AM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-win-gnu-32-opt
http://buildbot.rust-lang.org/builders/auto-win-gnu-32-opt/builds/3415

—
Reply to this email directly or view it on GitHub
#32141 (comment).

[bors]

⌛ Testing commit e926f28 with merge 06074ac...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt