Repository navigation
Back-compat risk: same label can be attached to distinct blocks in the same scope #21633
Description
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);
}
}
Activity
pnkfelix commentedon Jan 25, 2015
Nominating for P-backcompat-lang, 1.0 beta.
arielb1 commentedon Jan 28, 2015
isn't this just ordinary shadowing?
pnkfelix commentedon Jan 29, 2015
@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
'afor in type annotations.(Having said that, there is probably a coherent semantics that allows this based on shadowing.)
arielb1 commentedon Jan 29, 2015
The
'a's scope is theforloop's, just like thei.pnkfelix commentedon Jan 29, 2015
@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 commentedon Jan 29, 2015
Polish issue for 1.0, P-low.
pnkfelix commentedon Apr 3, 2015
(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 commentedon Apr 7, 2015
@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
Rollup merge of rust-lang#24162 - pnkfelix:fsk-detect-duplicate-loop-…
rollup merge of rust-lang#24162: pnkfelix/fsk-detect-duplicate-loop-l…
Merge pull request rust-lang#21633 from ChayimFriedman2/proc-macro-is…