const-propagated `arithmetic_overflow` in unreachable code

[cuviper]

Code

I tried this code: playground

fn main() {
    let x = 2u32;
    let y = 3u32;
    // ...
    if y <= x {
        dbg!(x - y);
    }
}

I expected to see this happen: compiles, nothing printed

Instead, this happened:

error: this arithmetic operation will overflow
 --> src/main.rs:6:14
  |
6 |         dbg!(x - y);
  |              ^^^^^ attempt to compute `2_u32 - 3_u32`, which would overflow
  |
  = note: `#[deny(arithmetic_overflow)]` on by default

The original code comes from macro-generated test cases in num-integer, which failed here:
rust-num/num-integer#54 (comment)

Version it worked on

It most recently worked on: 1.69.0-beta.3

Version with regression

rustc --version --verbose:

rustc 1.70.0-nightly (478cbb42b 2023-03-28)
binary: rustc
commit-hash: 478cbb42b730ba4739351b72ce2aa928e78e2f81
commit-date: 2023-03-28
host: x86_64-unknown-linux-gnu
release: 1.70.0-nightly
LLVM version: 16.0.0

@rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged

[cuviper]

Note that this only errors in a full build, not check.

cargo bisect-rustc identified b05bb29 -- cc #108872 @cjgillot @oli-obk

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

[cuviper]

@cjgillot I found that this is also failing in some num-traits test cases, and the new change doesn't help. Here's a minimization of that:

use std::cmp::Ordering::*;
fn main() {
    let max = u64::MAX as usize;
    match (usize::MAX as u64).cmp(&u64::MAX) {
        Greater => {
            dbg!(max + 1);
        }
        Equal | Less => {}
    }
}

$ rustc +nightly -V
rustc 1.70.0-nightly (28a29282f 2023-04-06)
$ rustc +nightly test.rs
error: this arithmetic operation will overflow
 --> test.rs:6:18
  |
6 |             dbg!(max + 1);
  |                  ^^^^^^^ attempt to compute `usize::MAX + 1_usize`, which would overflow
  |
  = note: `#[deny(arithmetic_overflow)]` on by default

This doesn't error if the Equal | Less is changed to _, or if the match is changed to if let.

I worry that this is a weakness in determining what is unreachable, especially if we were to expand that scenario to something that is not statically unreachable, only realized at runtime.