name-based comparison in new label-shadowing check has likely hygiene issues.

Opened by Felix S Klock II at 2024-12-12 23:08:36

Spawned off of #24162. Our lifetimes only carry a Name, not an Ident, which means the comparisons for shadowing are only doing name based comparisons.

But macros should be free to introduce labels, and have them be treated as independent due to hygiene.

This bug is believed to only introduce issues where code will cause a warning to be emitted by the new shadowing check when it should be accepted; i.e. there are not any known soundness issues associated with this problem.

(Note: While loop labels themselves are Idents, much of the syntax system does not treat them the same way it treats "normal" variables with respect to e.g. hygiene. For example the syntax::visit system does not invoke visit_ident on loop labels.)

It looks like it can't be fixed by a simple hygienic comparison (mtwt::resolve(ident1) == mtwt::resolve(ident2)) because every new label (or binding) gets fresh syntactic context even in the absence of macros:
```
fn main() {
    'a: loop {} // ctxt == 1
    'b: loop {} // ctxt == 2
    'a: loop {} // ctxt == 3
}
```
so, two label declarations are never equal if compared hygienically. I'm still studying mtwt and trying to understand what can be done with this issue.
Vadim Petrochenkov at 2015-10-06 01:20:24
@petrochenkov just because Idents have different syntax contexts, does not necessarily mean they are not equal. Calling resolve evaluates the name within the syntax context, it is quite possible, that resolve the same name in different contexts gives the same result, for example if the contexts contain renames which don't apply to the name.
Nick Cameron at 2015-11-04 05:41:33
In the example above mtwt::resolve(ident_of_a1) != mtwt::resolve(ident_of_a2) IIRC, so some other comparison has to be used to uncover the shadowing. I spent some time trying to find it, but gave up eventually.
Vadim Petrochenkov at 2015-11-04 12:50:48
That seems correct - they don't shadow. The shadowing case is:
```
'a: loop {
    'a: loop {}
}
```
I think hygienic equality is what we want, if that doesn't work, there might be a bug in the mtwt implementation.
Nick Cameron at 2015-11-04 19:04:21
According to the code and tests (https://github.com/rust-lang/rust/blob/master/src/test/compile-fail/loops-reject-duplicate-labels.rs) label duplication is supposed to be checked globally in a function, regardless of nesting (at least currently) (not sure why exactly). Some discussion here: https://github.com/rust-lang/rust/issues/21633
Vadim Petrochenkov at 2015-11-04 20:11:34
Heh, well that seems wrong to me, but explains why there is trouble doing hygienic comparison. I don't see an easy solution in this case (it's possible a different hygiene algorithm can fix this, or at least allow us to fix it with an easy-ish hack, but I don't think that counts as easy).
Nick Cameron at 2015-11-04 21:05:06
Also lol at that issue being E-Easy!
Nick Cameron at 2015-11-04 21:06:12
Ping @pnkfelix @petrochenkov @nrc still a problem?
Brian Anderson at 2017-04-11 16:50:57
@brson Yes, this is still an issue. This is probably solvable with new macro 2.0 hygiene machinery (cc @jseyfried as well).
Vadim Petrochenkov at 2017-04-11 17:08:18
This should "just work" in with declarative macros 2.0 (#40847) -- I'll add a test. In particular, lifetimes are now Ident, not just Names.
Jeffrey Seyfried at 2017-04-13 22:41:12
I believe the correct test case here is https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=baa075b80cf04df7f1f3f6b8389d82ff; this emits "warning: label name 'a shadows a label name that is already in scope" today but probably shouldn't since the labels are only shadowed across a macro expansion boundary.
Mark Rousskov at 2019-08-31 21:56:14