Array indexed by enum cast to usize no longer has bounds check eliminated

[jnlt3]

Rust compiler fails to eliminate bounds check when array is indexed by an enum cast to usize
Compiler explorer: https://godbolt.org/z/4o5cqT1eK

Code

pub enum Enum {
    A, B, C
}

pub fn func(inbounds: Enum, array: &[i16; 3]) -> i16 {
    array[inbounds as usize]
}

I expected the compiler to remove the bounds checks like it did previously however it failed to do so.

Version it worked on

It most recently worked on: Rust 1.63.0

Version with regression

rustc 1.64.0 (a55dd71d5 2022-09-19)
binary: rustc
commit-hash: a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52
commit-date: 2022-09-19
host: x86_64-unknown-linux-gnu
release: 1.64.0
LLVM version: 14.0.6

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

[Rageking8]

@rustbot label +T-compiler +A-codegen +I-slow

[clubby789]

Regressed in #96862

[nikic]

cc @oli-obk It looks like the necessary support code has already landed in #98332, so this should be a simple fix now?

[oli-obk]

@Dajamante is working on it

[scottmcm]

Note that this still works:

pub fn func(inbounds: &Enum, array: &[i16; 3]) -> i16 {
    array[*inbounds as usize]
}

So this is also the classic "LLVM doesn't have range metadata on parameters" problem.

(When there's a load, it gets !range metadata !{i8 0, i8 3}, which LLVM can then use to remove the comparison. But passed by value that metadata is unavailable.)

EDIT: Filed #102389 to discuss with lang whether that should compile. It didn't used to.

[MinusKelvin]

Should that work? Enum is not Copy so *inbounds is moving out of a shared reference. Or at least, that's what 1.63 says; 1.64 compiles it without any warnings. The 1.64 release notes say this about drop behavior:

• The Drop behavior of C-like enums cast to ints has changed. These are already discouraged by a compiler warning.

But I don't see why a change in drop behavior should affect whether a value is moved or not, and of course, there is no warning.