Check for duplicate loop labels in function bodies.

[pnkfelix]

Check for duplicate loop labels in function bodies.

See also: http://internals.rust-lang.org/t/psa-rejecting-duplicate-loop-labels/1833

The change, which we are putting in as future-proofing in preparation for future potential additions to the language (namely labeling arbitrary blocks and using those labels in borrow expressions), means that code like this will start emitting warnings:

fn main() {
    { 'a: loop { break; } }
    { 'a: loop { break; } }
}

To make the above code compile without warnings, write this instead:

fn main() {
    { 'a: loop { break; } }
    { 'b: loop { break; } }
}

Since this change is only introducing a new warnings, this change is non-breaking.

Fix #21633

[rust-highfive]

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

[pnkfelix]

(this isn't really done; at the very least, it needs a test or two, and I want to wait to see feedback from the internals thread.)

[pnkfelix]

Okay, added tests, and I guess the internals thread isn't going to get much action now.

r? @nikomatsakis

[nikomatsakis]

r+ modulo nit

[pnkfelix]

@bors r=nikomatsakis 816a500 rollup

[pnkfelix]

@nikomatsakis Mind skimming over the additions from ed5ac77 ?

[pnkfelix]

@nikomatsakis this definitely needs a re-review now.

[nikomatsakis]

@pnkfelix r+ modulo nit (your call on whether to make an issue)

This actually does feel cleaner to me. Doing the pre-pass to collect the labels is nice.

[pnkfelix]

@bors r=nikomatsakis e6880ab rollup

[pnkfelix]

@bors r- (there's some test fallout I need to address)

[pnkfelix]

(no this still does not work...)

[pnkfelix]

(The main difficulty remaining is the handling of hygiene. My current approach to collapsing the rules so that labels are scoped to the entire function body does not play well with our (mis)handling of hygiene for lifetime-like things... at this point this might not happen for 1.0, in which case we will just have to live with the unfortunate scoping rules and work around them if we add e.g. &'lifetime <expr>expressions in the future.)

[pnkfelix]

@bors r=nikomatsakis 464e586

[bors]

⌛️ Testing commit 464e586 with merge 1fd19cf...

[bors]

💔 Test failed - auto-linux-64-nopt-t

[steveklabnik]

@pnkfelix travis only runs make tidy, it doesn't actually do a build

[pnkfelix]

@steveklabnik ah, I had been under the impression that it did a make rustc-stage1 but did not do any testing of the result. Okay.

[pnkfelix]

@bors r=nikomatsakis 2b3cd40

[steveklabnik]

long ago it did, but it would time out and such so https://github.com/rust-lang/rust/blob/master/.travis.yml#L17

[steveklabnik]

@bors: rollup-

[bors]

⌛️ Testing commit 2b3cd40 with merge 2baf348...

[steveklabnik]

Since this is future-proofing, I'm adding beta-nominated

[alexcrichton]

@bors: p=1

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-32-nopt-t, auto-win-32-opt, auto-win-64-nopt-t, auto-win-64-opt

[pnkfelix]

@steveklabnik wrote:

long ago it did, but it would time out and such so https://github.com/rust-lang/rust/blob/master/.travis.yml#L17

ah. Maybe we could try doing a "build" that just runs the type+borrow checking for a stage1 build, via -Z no-trans ... that in combination with not doing an LLVM build could be "sufficiently speedy", maybe ...

Update: never mind, that would not suffice today, since -Z no-trans today does not generate any output, and thus we would not have the metadata that later crates need after compiling the first crate.

[pnkfelix]

i was not sure about whether to accept, but since it is already part of alex's rollup:

going from nominated to (nominated, accepted)