Repository navigation
Name resolution has changed between 1.7.0 and 1.8.0 #33458
Description
Activity
cc @jseyfried @nrc
FWIW I think 62 makes more sense, intuitively speaking, but the subtle change is a bit terrifying
Nominating for T-lang discussion.
This likely means that the change wasn’t communicated well enough?
Yes, for future reference, anything marked
[breaking-change]should also have the relnotes tag applied.We discussed this in the @rust-lang/lang meeting. The conclusion was that the change was legit (a bug fix), but there was a process failure in that we failed to tag the breaking change with "relnotes". D'oh, but I think this change had only very minor impact in practice?
I think this change had only very minor impact in practice?
I also think so. I sometimes stumble upon such dark corners of the language, but it is only because we try to reimplement compiler fronted in IntelliJ Rust.
We probably should close the issue, thanks for the clarification!
I agree that this change had very minor impact in practice -- constants and local variables can only have the same name by violating naming conventions, and
consts in deep blocks are already uncommon.We have landed other [breaking-change] bug fixes with similarly low likelihoods of breakage (#32923, #32134, #32006, #31908, #31824, #30866, #30295, #30294, #32141, #31461) -- should these all have been tagged
relnotesas well?Reacted by Jake GouldingI think yes, they should be in the release notes. The release notes might help someone figuring out what's going on when they see some code breaking (maybe a breaking change had unintended/unforeseen consequences)
I think this is the intended behavior and the issue should be closed.
The following program:
prints
92with rustc 1.7.0 and62with rustc 1.8.0. Is this intentional? I have not found a mention in the release notes. Also the reference could be a bit more clear on the scoping rules :)