Internal compiler error caused by wrapping Error from nanomsg crate in enum

[fuine]

Minimal test case (thanks creduce):

extern crate nanomsg;
use nanomsg::Error;

enum A {
    B(Error)
}

fn main() { }

Backtrace:

thread 'rustc' panicked at 'invalid lint-id `trivial_numeric_casts`', /checkout/src/librustc/lint/context.rs:1322
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:355
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:365
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:549
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:511
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:495
   7: <rustc::ty::context::TypeckTables<'tcx> as serialize::serialize::Decodable>::decode::{{closure}}
   8: rustc_metadata::decoder::<impl rustc_metadata::cstore::CrateMetadata>::item_body_tables
   9: rustc_metadata::cstore_impl::provide::typeck_tables
  10: rustc::ty::maps::<impl rustc::ty::maps::queries::typeck_tables<'tcx>>::try_get
  11: rustc::ty::maps::<impl rustc::ty::maps::queries::typeck_tables<'tcx>>::get
  12: rustc::ty::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::item_tables
  13: rustc_const_eval::eval::const_eval
  14: rustc::ty::maps::<impl rustc::ty::maps::queries::const_eval<'tcx>>::try_get
  15: rustc::ty::maps::<impl rustc::ty::maps::queries::const_eval<'tcx>>::get
  16: rustc::ty::layout::Layout::compute_uncached
  17: rustc::ty::util::<impl rustc::ty::TyS<'tcx>>::layout
  18: <collections::vec::Vec<T> as collections::vec::SpecExtend<T, I>>::from_iter
  19: rustc::ty::layout::Layout::compute_uncached
  20: <rustc_lint::types::VariantSizeDifferences as rustc::lint::LateLintPass<'a, 'tcx>>::check_item
  21: rustc::lint::context::LintContext::with_lint_attrs
  22: <rustc::lint::context::LateContext<'a, 'tcx> as rustc::hir::intravisit::Visitor<'tcx>>::visit_mod
  23: rustc::lint::context::check_crate
  24: rustc_driver::driver::phase_3_run_analysis_passes::{{closure}}
  25: rustc::ty::context::TyCtxt::create_and_enter
  26: rustc_driver::driver::phase_3_run_analysis_passes
  27: rustc_driver::driver::compile_input
  28: rustc_driver::run_compiler
  29: std::panicking::try::do_call
  30: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
  31: <F as alloc::boxed::FnBox<A>>::call_box
  32: std::sys::imp::thread::Thread::new::thread_start
             at /checkout/src/liballoc/boxed.rs:650
             at /checkout/src/libstd/sys_common/thread.rs:21
             at /checkout/src/libstd/sys/unix/thread.rs:84
  33: start_thread
  34: __clone

cargo version:

cargo 0.19.0 (28d1d60d4 2017-05-16)
release: 0.19.0
commit-hash: 28d1d60d4b634b70d7ceb0808144f2337c83ab95
commit-date: 2017-05-16

rustc version:

rustc 1.18.0 (03fc9d622 2017-06-06)
binary: rustc
commit-hash: 03fc9d622e0ea26a3d37f5ab030737fcca6928b9
commit-date: 2017-06-06
host: x86_64-unknown-linux-gnu
release: 1.18.0
LLVM version: 3.9

[fuine]

What is maybe an interesting additional information is that originally I got this error in a different setting:

let mut buffer = vec![0; 100];
let a = match socket.nb_read(buffer.as_mut_slice()) {
    Ok(_) => // do something here
    Err(Error::TryAgain) => // do something else here
    Err(e) => println!("{}", e)
};

where socket was a bound nanomsg's Socket.
The above code worked, but if i switched nb_read to just read and commented out the pattern match on nanomsg's Error::TryAgain it triggered the ICE. This snippet (after mentioned changes) works on its own, but incorporated into my significantly more complex code base it resulted in the ICE.

[blabaere]

Switching from nb_read to read changes the type of the value being matched. read comes from std::io::Read while nb_read returns a Result whose error is not std::io::Error but nanomsg::Error.
nanomsg::Error has has the trait From<std::io:Error>. Not sure if this has any impact.

[Mark-Simulacrum]

Is there a chance you could narrow this down to something that doesn't require nanomsg?

[blabaere]

The initial report contains a minimal test to reproduce the problem without nanomsg. I added info about the original problem with nanomsg, just in case.

[Mark-Simulacrum]

Could you repaste it into a comment? The only test I see in the initial report is below, and it contains nanomsg I believe..

extern crate nanomsg;
use nanomsg::Error;

enum A {
    B(Error)
}

fn main() { }

[blabaere]

Sorry, I've talked too fast. I will try to extract the nanomsg::Error related code and post a stand-alone example.

[blabaere]

I finally found some time for the "minimal" code. Here it is, with no less than three crates ! I have not been able to reproduce the problem with a smaller structure.

[Mark-Simulacrum]

Hm, actually, looking at this more, I think this was #42007 which is fixed in nightly and beta. If possible, could you check whether that's the case for you (that the actual bug doesn't reproduce anymore)?

[blabaere]

Confirmed, it works fine with the following versions:

rustc 1.19.0-beta.2 (a175ee509 2017-06-15)
binary: rustc
commit-hash: a175ee509bca5069b01cea9a35c6f333d2250eee
commit-date: 2017-06-15
host: x86_64-unknown-linux-gnu
release: 1.19.0-beta.2
LLVM version: 4.0

rustc 1.20.0-nightly (c9bb93576 2017-06-24)
binary: rustc
commit-hash: c9bb93576d4484edd1b3c40eb2aea0dfa0788851
commit-date: 2017-06-24
host: x86_64-unknown-linux-gnu
release: 1.20.0-nightly
LLVM version: 4.0

[Mark-Simulacrum]

Would you mind if we closed this issue then? Seems like there's nothing left to do here--I don't think we'll want to release a patch stable release for this...

[blabaere]

I'm not the one who opened it in the first place, maybe @fuine has on opinion on that.

[Mark-Simulacrum]

Ah, right. Well, I'll close for now actually and if they disagree I'll reconsider.

[fuine]

If this is resolved in beta/nightly then I'm ok with closing the issue, thanks for help!