Repr Enum Bug

[chasewalden]

I stumbled across this while I was trying to do some very, extremely unsafe casting between any/all types to i64. I found the #[repr(<type>) syntax earlier today and decided to give this a spin. It did not make the compiler happy at all.

#[repr(i64)]
#[derive(Debug)]
enum MyEnum<T> {
    MyVariant(T),
}

...

println!("{:?}", MyEnum::MyVariant("Hello World"));

yields

thread 'rustc' panicked at 'assertion failed: `(left == right)` (left: `ReprInt(src/lib.rs:177:12: 177:15, SignedInt(i64))`, right: `ReprAny`)', ../src/librustc/ty/layout.rs:951
stack backtrace:
   1:        0x10919450e - std::sys::backtrace::tracing::imp::write::h29f5fdb9fc0a7395
   2:        0x1091a35ff - std::panicking::default_hook::_{{closure}}::h2cc84f0378700526
   3:        0x1091a1b0d - std::panicking::default_hook::hbbe7fa36a995aca0
   4:        0x1091a21a7 - std::panicking::rust_panic_with_hook::h105c3d42fcd2fb5e
   5:        0x1091a2064 - std::panicking::begin_panic::hbf62ea4a5ff3f9de
   6:        0x1091a1f72 - std::panicking::begin_panic_fmt::h20f5943904e5791d
   7:        0x10598b14b - rustc::ty::layout::Layout::compute_uncached::h52016a57380b87fc
   8:        0x104b266da - rustc::ty::util::_<impl rustc..ty..TyS<'tcx>>::layout::h6e715527ac894584
   9:        0x104b2e5bf - rustc::infer::InferCtxtBuilder::enter::hafc62a0131a2dfab
  10:        0x104c6b65d - rustc_trans::type_of::sizing_type_of::ha156764ed6a49454
  11:        0x104b7b87b - rustc_trans::abi::FnType::unadjusted::h83ea175ee374368f
  12:        0x104bfcd4b - rustc_trans::declare::declare_fn::h54ad486bf2f83536
  13:        0x104c61f87 - rustc_trans::trans_item::TransItem::predefine::habe2be2cf7d59b5d
  14:        0x104b9cbf2 - rustc_trans::base::trans_crate::h9baf3a0389546061
  15:        0x1046a050a - rustc_driver::driver::phase_4_translate_to_llvm::h54e99578fb1bb696
  16:        0x1046dd72c - rustc_driver::driver::compile_input::_{{closure}}::h7236bd0d96fe8ce9
  17:        0x1046d03ba - rustc_driver::driver::phase_3_run_analysis_passes::_{{closure}}::h7f2cec505064b4bf
  18:        0x10462c3a5 - rustc::ty::context::TyCtxt::create_and_enter::hab8fd8369376d0f6
  19:        0x10468bea1 - rustc_driver::driver::compile_input::hb4cc34cf85dc1edf
  20:        0x1046b2d30 - rustc_driver::run_compiler::h50f95674bd902ab5
  21:        0x1046030de - std::panicking::try::call::h4577500a5284c6ff
  22:        0x1091aa47a - __rust_maybe_catch_panic
  23:        0x10461b5d1 - _<F as alloc..boxed..FnBox<A>>::call_box::h24f3eb0b42327962
  24:        0x1091a08b5 - std::sys::thread::Thread::new::thread_start::h8f3bd45211e9f5ea
  25:     0x7fff9a683c12 - _pthread_body
  26:     0x7fff9a683b8f - _pthread_start

Side note: there are a bunch of C libraries that I have used that have duplicate enum entries

i.e.

enum Something {
     Thing1 = 1,
     Thing2 = 2,
     AnotherThing = 2,
     // etc.
}

Currently, we are not allowed to have duplicate values if we are trying to make an enum for use with the FFI, which in these cases, makes wrapping somewhat difficult.

[jonas-schievink]

Duplicate of #34571

[chasewalden]

Cheers. I didn't even think to check if this was already reported.