New deny(const_err) in unreachable code

[cuviper]

use std::{u64, usize};

fn main() {
    if (usize::MAX as u64) < u64::MAX {
        println!("{}", 1 + usize::MAX as u64);
    } else {
        println!("disqualified!");
    }
}

(playground)

This compiles and runs fine on a 32-bit target, but fails on 64-bit 1.29.0-beta.1:

error: attempt to add with overflow
 --> src/main.rs:5:24
  |
5 |         println!("{}", 1 + usize::MAX as u64);
  |                        ^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[deny(const_err)] on by default

The same code is fine without even a warning on 64-bit stable 1.27.2. It's also fine on the pre-release 1.28.0 where const-err became deny-by-default (#50653), because the lint isn't triggering at all.

I'm guessing that const-eval is just evaluating more now, thus triggering the lint more often. If this is decided not to be called a regression, it at least warrants a release note for 1.29.

[oli-obk]

I'm fairly certain this used to also lint last year. This lint occurring again is due to a regression fix for #49760

[pnkfelix]

Assigning high priority, not because this is necessarily a bug that needs to be fixed, but rather so that we remember that we need to decide 1. whether it is a bug, and 2. if its not a bug, whether it warrants release notes.

[cuviper]

I'm fairly certain this used to also lint last year.

Hmm, you're right -- rustc 1.10 through 1.25 do lint this as a warning. 1.26 through 1.28 do not, and now 1.29 lints it again, denied by default.

[nikomatsakis]

We discussed this in the compiler meeting.

Since this won't affect dependencies, it's not a "true regression", and we're inclined to leave it as is -- @cuviper, thoughts?

(You could also downgrade the lint to allow if desired, of course.)

[cuviper]

I'm ok with that.

[nikomatsakis]

OK, closing. Thanks @cuviper!