there's no #[allow(shadowed_label_names)]

[durka]

The warning about shadowed label names can't be turned off. Seems like it ought to have some name and be under the "future incompatible" lint group.

EDIT (ehuss):

Example:

// Doesn't matter where these are defined, as long as they are in the same function.
'a: loop { break 'a; }
'a: loop { break 'a; } // warning: loop name `'a` shadows a label name that is already in scope

Warning added in #24162, see also #21633 and https://internals.rust-lang.org/t/psa-rejecting-duplicate-loop-labels/1833.

[jonas-schievink]

This might become a hard error later, so it doesn't seem like a good idea to turn the warning off

[durka]

Seems like the same argument could be applied to the other future-incompatibility lints. What even is the plan for a feature that might make duplicate labels within a function a problem? goto 'a‽

Also, there are false positives of this warning (for example, a label name within a closure). I will file a separate bug, but false positives would be a motivation for locally turning off the warning.

[jonas-schievink]

I think there was this idea of allowing nameable regions ('a: { /* stuff */ }), other than that, I don't know

[steveklabnik]

Triage: not aware of any changes

[durka]

Is the compiler team planning to make the needed decision? ;) Otherwise we should just close.

[petrochenkov]

Fun fact: I-needs-decision issues are not looked at during compiler team triage meetings.
cc @pnkfelix

[petrochenkov]

This doesn't need decision, just implementation - with current state of hygiene false positives can just be fixed and everything else turned into hard errors (this stuff issued deprecation warnings for very long time).

I'll r+ a PR turning this into a deny-by-default lint as well.

[Centril]

Could someone add a reproducer to this issue?

[WiSaGaN]

Is there any reasonable possibility that we will actually implement the feature that has the future-imcompatibility issue?