Name resolution has changed between 1.7.0 and 1.8.0

[matklad]

The following program:

fn main() {
    let x: i32 = 92;
    {
        const x: i32  = 62;
        println!("{}", x);
    }
}

prints 92 with rustc 1.7.0 and 62 with 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 :)

[jonas-schievink]

cc @jseyfried @nrc

FWIW I think 62 makes more sense, intuitively speaking, but the subtle change is a bit terrifying

[nagisa]

Nominating for T-lang discussion.

[jseyfried]

This was intentional, see #31105.

[nagisa]

This likely means that the change wasn’t communicated well enough?

[aturon]

Yes, for future reference, anything marked [breaking-change] should also have the relnotes tag applied.

[nikomatsakis]

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?

[matklad]

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!

[jseyfried]

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 relnotes as well?

[shahn]

I 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)

[matklad]

I think this is the intended behavior and the issue should be closed.