Compiler crashes when trying to use std::ops::Sized

[torkleyy]

Minimal example

use std::ops::Sized;

struct Test<T: ?Sized>;

fn main() {}

I tried to build a struct for a generic type T which does not have to be sized.
Accidentally, I used std::ops::Sized instead of std::marker::Sized so the compiler
crashed.

Just doing use std::ops::Sized; without actually using it in the code does not crash the compiler.

Build platform

Operating system:

elementary OS (based on Ubuntu)

rustc --version --verbose:

rustc 1.12.0 (3191fbae9 2016-09-23)
binary: rustc
commit-hash: 3191fbae9da539442351f883bdabcad0d72efcb6
commit-date: 2016-09-23
host: x86_64-unknown-linux-gnu
release: 1.12.0

Compiler output

Output:

Compiling sized_bug v0.1.0 (file:///home/thomas/Workspace/Idea/sized_bug)
     Running `/home/thomas/.cargo/bin/rustc src/main.rs --crate-name sized_bug --crate-type bin -g -C metadata=f13e3628c6af8bb3 --out-dir /home/thomas/Workspace/Idea/sized_bug/target/debug --emit=dep-info,link -L dependency=/home/thomas/Workspace/Idea/sized_bug/target/debug/deps`
error[E0432]: unresolved import `std::ops::Sized`. There is no `Sized` in `std::ops`
 --> src/main.rs:1:5
  |
1 | use std::ops::Sized;
  |     ^^^^^^^^^^^^^^^

error: internal compiler error: ../src/librustc/hir/def.rs:135: attempted .def_id() on invalid def: Err
[Backtrace]

Backtrace:

thread 'rustc' panicked at 'Box<Any>', ../src/librustc_errors/lib.rs:634
stack backtrace:
   1:     0x7f1b78d87d99 - std::sys::backtrace::tracing::imp::write::h00e948915d1e4c72
   2:     0x7f1b78d985dc - std::panicking::default_hook::_{{closure}}::h7b8a142818383fb8
   3:     0x7f1b78d969d4 - std::panicking::default_hook::h41cf296f654245d7
   4:     0x7f1b78d97138 - std::panicking::rust_panic_with_hook::h4cbd7ca63ce1aee9
   5:     0x7f1b72570ac7 - std::panicking::begin_panic::hd3e81d866d6c5b0a
   6:     0x7f1b725816a5 - rustc_errors::Handler::bug::h60f29cdeff67c1a3
   7:     0x7f1b75ff8054 - rustc::session::opt_span_bug_fmt::_{{closure}}::ha1319a72e07cd73b
   8:     0x7f1b75f39545 - rustc::session::opt_span_bug_fmt::h4badbc71bfeea6f9
   9:     0x7f1b75f39382 - rustc::session::bug_fmt::he780dcb9e1e8a7d5
  10:     0x7f1b75dd04b1 - rustc::hir::def::Def::def_id::hee85e7d3aef08204
  11:     0x7f1b774440ab - rustc_typeck::collect::compute_bounds::ha308332ebf513c1d
  12:     0x7f1b7743fdac - rustc_typeck::collect::ty_generic_predicates::h20f4b7021c2bd11a
  13:     0x7f1b7743db28 - rustc_typeck::collect::convert_typed_item::hee7e4ecf31154291
  14:     0x7f1b7743488f - rustc_typeck::collect::convert_item::h3118362fcab2a9a8
  15:     0x7f1b7742be1f - rustc_typeck::collect::collect_item_types::hd3ea446dd2da1ed8
  16:     0x7f1b7745806b - rustc_typeck::check_crate::h5c76faa7ac951c22
  17:     0x7f1b7917c1b3 - rustc_driver::driver::phase_3_run_analysis_passes::_{{closure}}::he5bb0058670d90b6
  18:     0x7f1b790cd158 - rustc::ty::context::TyCtxt::create_and_enter::h1ad8faffb62f0367
  19:     0x7f1b7913581f - rustc_driver::driver::compile_input::h4d6bc655b7baad10
  20:     0x7f1b79162776 - rustc_driver::run_compiler::h9165e61fc2dd486f
  21:     0x7f1b790a96e2 - std::panicking::try::do_call::hc52dd3bdae996640
  22:     0x7f1b78da6746 - __rust_maybe_catch_panic
  23:     0x7f1b790c2d7a - _<F as alloc..boxed..FnBox<A>>::call_box::h3aad53cfb9d2713a
  24:     0x7f1b78d94d32 - std::sys::thread::Thread::new::thread_start::h4c0ad33b336bc6ea
  25:     0x7f1b71d18709 - start_thread
  26:     0x7f1b789d882c - clone
  27:                0x0 - <unknown>

[memoryleak47]

Also occures on nightly

rustc 1.14.0-nightly (3f4408347 2016-10-27)
binary: rustc
commit-hash: 3f4408347d2109803edbf53c89c8bce575de4b67
commit-date: 2016-10-27
host: x86_64-unknown-linux-gnu
release: 1.14.0-nightly
LLVM version: 3.9

[TimNN]

Technically, this is a regression from 1.7 to 1.8.

[nikomatsakis]

Works for any trait name, see https://is.gd/15w6hz:

struct Foo<T: ?Hash> { }

fn main() { }

[eddyb]

This is due to error recovery, i.e. the compiler not stopping on errors (name resolution in this case).
My guess is that these lines were never accounting for Def::Err existing.
The solution would be to use trait_def != Def::Trait(kind_id) where trait_def is tcx.expect_def(tpb.ref_id) (i.e. avoid calling .def_id() - that's where this ICE comes from).