Back-compat risk: same label can be attached to distinct blocks in the same scope

[pnkfelix]

The current Rust alpha allows one to attach two lifetimes with the same name to two distinct loop blocks.

This is a backwards compatibility risk for hypothesized future versions of Rust where the lifetime labels can be used in e.g. type annotations (rather than solely used for labelled break/continue statements).

Example:

fn main() {
    let d = 3;
    'a: for i in (0..d).rev() {
        println!("i: {}", i);
    }

    'a: for i in (d..d*2).rev() {
        println!("i: {}", i);
    }
}

[pnkfelix]

Nominating for P-backcompat-lang, 1.0 beta.

[arielb1]

isn't this just ordinary shadowing?

[pnkfelix]

@arielb1 in my opinion ordinary shadowing would be when an nested scope is labeled with the same lifetime as a scope is nested within.

I see the two scopes here as siblings, at least in terms of what we might use 'a for in type annotations.

(Having said that, there is probably a coherent semantics that allows this based on shadowing.)

[arielb1]

The 'a's scope is the for loop's, just like the i.

[pnkfelix]

@arielb1 ah. okay yes, that is another coherent semantics, I think. Not sure if its the one I would pick, but I do not see any obvious holes in it.

[pnkfelix]

Polish issue for 1.0, P-low.

[pnkfelix]

(i spent a little while looking into this. It may be a little tricky to do at certain phases of the compiler, because the current for-loop expansion moves the label into the inside of a block (basically implicitly building in the scoping semantics outlined by @arielb1 above), so I don't think I can meaningfully do the analysis post expansion, at least, not without knowing enough to skip over such blocks as not introducing an inner scope.)

current branch is here: pnkfelix@fsk-detect-duplicate-loop-labels

---

semi-ironically, I think the fact that the loop-label ends up inside a block in the expansion is my own fault; due to #21984

[pnkfelix]

@nikomatsakis suggests that we strengthen this to simply disallow any duplicate labels in the body of an entire function. That would certainly resolve my above problem.

Update: posted general warning that we'll be adopting this strategy to internals: http://internals.rust-lang.org/t/psa-rejecting-duplicate-loop-labels/1833