Decide on semantics for enum -> integer casts on non-Copy enums.

[eddyb]

Casting an enum which does not derive Copy to an integer moves atm:

enum E {
    A = 0,
    B = 1,
    C = 2
}

fn main() {
    let e = E::C;
    assert_eq!(e as u32, 2);
    assert_eq!(e as u32, 2); // error: use of moved value: `e`
}

This matches the behavior of other coercions/casts, specifically unsizing ones (Box<T> -> Box<Trait>).

However, one difference arises between old trans and MIR trans, wrt drops:

enum E {
    A = 0,
    B = 1,
    C = 2
}

impl Drop for E {
    fn drop(&mut self) {
        println!("drop");
    }
}

fn main() {
    let e = E::C;
    assert_eq!(e as u32, 2);
}

On stable, old trans will run the destructor exactly once. After #35764, MIR trans doesn't run it at all.
The reason is that the move that borrowck knows about causes the drops in MIR to be statically elided, whereas old trans forgot(?) to drop-fill e, resulting in the variable being dropped at end of scope.

Should the drop execute or not? IMO it's good to have uniformity between all moving operations.

[Aatch]

The safe option is, of course, to execute the drop. However I think that not running makes more sense to me. For one, it would match the semantics of transmute, which is the only other way to get this kind of situation (converting from a type that impls to one that doesn't).

Another option, though it would be more breaking than either already mentioned, would be to disallow enum -> int casts where the enum implements Drop.

[arielb1]

My original intent when I wrote the conversion code was to execute the drop. That was before mem::forget was made safe, so it was the only option.

[nikomatsakis]

We discussed this in the @rust-lang/lang meeting. We like the idea of making it an error to coerce an enum to an integer if that enum type supports Drop -- presuming it doesn't have impact in practice (which seems likely).

[nikomatsakis]

triage: P-medium

[oli-obk]

Some mentoring instructions of how I think this could be implemented:

1. Turn the match arm body

   rust/src/librustc_typeck/check/cast.rs

   Line 619 in 3bf71b3

   (Int(CEnum), Int(_)) => Ok(CastKind::EnumCast),

   into a function call similar to all the check_X_Y_cast functions.
2. Add check whether the self.expr_ty has a destructor (you can use the has_dtor meethod for this, but that method takes a TyCtxt so you need to pass an fcx to your new function just like some of the other check_X_Y_cast functions do.
3. If the type has a destructor, create a new error variant in

   rust/src/librustc_typeck/check/cast.rs

   Line 152 in 3bf71b3

   enum CastError {

   and report that. This will also require you to actually emit an error in

   rust/src/librustc_typeck/check/cast.rs

   Line 217 in 3bf71b3

   fn report_cast_error(&self, fcx: &FnCtxt<'a, 'tcx>, e: CastError) {

   (the compiler will tell you to handle the new error variant). Create a structured error similar to how https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/check/cast.rs#L358-L366 works.