Back-compat risk: same label can be attached to distinct blocks in the same scope #21633
Comments
|
Nominating for P-backcompat-lang, 1.0 beta. |
|
isn't this just ordinary shadowing? |
|
@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 (Having said that, there is probably a coherent semantics that allows this based on shadowing.) |
|
The |
|
@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. |
brson
added
the
E-easy
|
Polish issue for 1.0, P-low. |
|
(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 |
|
@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 |
…labels, r=nikomatsakis Check for duplicate loop labels in function bodies. See also: http://internals.rust-lang.org/t/psa-rejecting-duplicate-loop-labels/1833 Fix rust-lang#21633
…ikomatsakis 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: ```rust fn main() { { 'a: loop { break; } } { 'a: loop { break; } } } ``` To make the above code compile without warnings, write this instead: ```rust fn main() { { 'a: loop { break; } } { 'b: loop { break; } } } ``` Since this change is only introducing a new warnings, this change is non-breaking. Fix #21633
…abels 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: ```rust fn main() { { 'a: loop { break; } } { 'a: loop { break; } } } ``` To make the above code compile without warnings, write this instead: ```rust fn main() { { 'a: loop { break; } } { 'b: loop { break; } } } ``` Since this change is only introducing a new warnings, this change is non-breaking. Fix rust-lang#21633
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:
The text was updated successfully, but these errors were encountered: