Should C-style enums silently overflow?

[pnkfelix]

Spawned off of a note from PR #22532 on commit 1246d40

The following program:

#[repr(usize)]
enum Foo {
    A = 0xffffffffffffffff_usize,
    B,
    C
}

fn main() {
    println!("Hello World: {:x}", Foo::A as usize);
    println!("Hello World: {:x}", Foo::B as usize);
    println!("Hello World: {:x}", Foo::C as usize);
}

compiles and prints:

Hello World: ffffffffffffffff
Hello World: 0
Hello World: 1

My personal preference would be for a compiler error due to the implicit overflow, with a note saying that the programmer should explicitly assign some value to Foo::B. (And thus they can opt into the current behavior by assigning it B = 0,; then Foo::C would continue to be assigned 1 as today.)

[pnkfelix]

triage: I-nominated

(I suggest P-backcompat-lang, I-needs-decision.)

[pnkfelix]

@nrc is it by design that highfive responded to the above comment by assigning the 1.0 beta milestone?

[nrc]

Hmm, no it is not, I guess it tried to find the milestone "I suggest P-backcompat-lang, I-needs-decision.", but I have no idea how it ended up with "1.0 beta". I'll look into it (also, I'll only check inside parens on the same line

[pnkfelix]

1.0 beta, P-backcompat-lang.

[theemathas]

Is this the same as #23235?

[pnkfelix]

@theemathas I'd say they are duplicates, except that this bug (I think) is a little more general.

[pnkfelix]

So, we do check for overflow in one case, namely for an overflow from u64::MAX wrapping around to 0_u64.

(This ends up being treated as equivalent to -1_i64 being incremented to 0_i64; see also #23221.)

That check is done here in ty.rs

I'm going to try to generalize it to handle the specific repr's properly. (That will hopefully help fix #23221.)