Compiler panics unexpectedly in 1.31 when constructing struct with wrong syntax

[chridou]

The compiler crashes when constructing a struct syntactically wrong.

Simply paste the code below into the playground.

I tried this code:

struct Foo {
    t: u32,
}

impl Foo {
    fn new(t: u32) -> Self {
        Self(t) // wrong. Should be Self{t}
    }
}

fn main() {
    println!("Hello, world!");
}

This is the compiler output:

Compiling playground v0.0.1 (/playground)
error[E0658]: `Self` struct constructors are unstable (see issue #51994)
 --> src/main.rs:7:9
  |
7 |         Self(t) // wrong. Should be Self{t}
  |         ^^^^

error: internal compiler error: librustc/hir/def.rs:265: attempted .def_id() on invalid def: SelfCtor(DefId(0/0:4 ~ playground[8d9a]::{{impl}}[0]))

thread 'main' panicked at 'Box<Any>', librustc_errors/lib.rs:600:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0658`.

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.31.0 (abe02cefd 2018-12-04) running on x86_64-unknown-linux-gnu

note: compiler flags: -C codegen-units=1 -C debuginfo=2 --crate-type bin

note: some of the compiler flags provided by cargo are hidden

error: Could not compile `playground`.

To learn more, run the command again with --verbose.

[estebank]

error: internal compiler error: src/librustc/hir/def.rs:265: attempted .def_id() on invalid def: SelfCtor(DefId(0/0:4 ~ playground[8317]::{{impl}}[0]))

thread 'main' panicked at 'Box<Any>', src/librustc_errors/lib.rs:600:9
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:211
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:227
   4: rustc::util::common::panic_hook
   5: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:495
   6: std::panicking::begin_panic
   7: rustc_errors::Handler::bug
   8: rustc::util::bug::opt_span_bug_fmt::{{closure}}
   9: rustc::ty::context::tls::with_opt::{{closure}}
  10: rustc::ty::context::tls::with_context_opt
  11: rustc::ty::context::tls::with_opt
  12: rustc::util::bug::opt_span_bug_fmt
  13: rustc::util::bug::bug_fmt
  14: rustc::hir::def::Def::def_id::{{closure}}
  15: rustc::hir::def::Def::def_id
  16: rustc_typeck::check::callee::<impl rustc_typeck::check::FnCtxt<'a, 'gcx, 'tcx>>::confirm_builtin_call
  17: rustc_typeck::check::FnCtxt::check_expr_kind
  18: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
  19: rustc_typeck::check::FnCtxt::check_block_with_expected
  20: rustc_typeck::check::FnCtxt::check_expr_kind
  21: rustc_typeck::check::FnCtxt::check_expr_with_expectation_and_needs
  22: rustc_typeck::check::FnCtxt::check_return_expr
  23: rustc_typeck::check::check_fn
  24: rustc::ty::context::tls::with_related_context
  25: rustc::infer::InferCtxtBuilder::enter
  26: rustc_typeck::check::typeck_tables_of
  27: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::typeck_tables_of<'tcx>>::compute
  28: rustc::dep_graph::graph::DepGraph::with_task_impl
  29: <rustc::ty::query::plumbing::JobOwner<'a, 'tcx, Q>>::start
  30: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  31: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  32: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::ensure_query
  33: rustc::session::Session::track_errors
  34: rustc_typeck::check::typeck_item_bodies
  35: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::typeck_item_bodies<'tcx>>::compute
  36: rustc::dep_graph::graph::DepGraph::with_task_impl
  37: <rustc::ty::query::plumbing::JobOwner<'a, 'tcx, Q>>::start
  38: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  39: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  40: rustc::util::common::time
  41: rustc_typeck::check_crate
  42: rustc::ty::context::tls::enter_context
  43: <std::thread::local::LocalKey<T>>::with
  44: rustc::ty::context::TyCtxt::create_and_enter
  45: rustc_driver::driver::compile_input
  46: rustc_driver::run_compiler_with_pool
  47: <scoped_tls::ScopedKey<T>>::set
  48: rustc_driver::run_compiler
  49: rustc_driver::monitor::{{closure}}
  50: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:102
  51: rustc_driver::run
  52: rustc_driver::main
  53: std::rt::lang_start::{{closure}}
  54: std::panicking::try::do_call
             at src/libstd/rt.rs:59
             at src/libstd/panicking.rs:310
  55: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:102
  56: std::rt::lang_start_internal
             at src/libstd/panicking.rs:289
             at src/libstd/panic.rs:398
             at src/libstd/rt.rs:58
  57: main
  58: __libc_start_main
  59: <unknown>
query stack during panic:
#0 [typeck_tables_of] processing `Foo::new`
#1 [typeck_item_bodies] type-checking all item bodies
end of query stack
error: aborting due to previous error

[alexreg]

I'm presently looking into this. Let me know if you have thoughts please, @estebank.

[estebank]

@alexreg the ICE happens because of the unconditional attempt to get the span for the given defid:

rust/src/librustc_typeck/check/callee.rs

Line 283 in 3a75e80

_ => self.tcx.hir().span_if_local(def.def_id())

You will need to add a check for SelfCtor and either forego the convenient span or find a way to get the defid (and subsequent span) of the current type (which might be hard to do, but should be something along the lines of impl <Trait> for <UNDERLINE_THIS> {).

I don't think this existing code already handles the "used parens instead of braces" case, but there's code to account for it which might have to also be adjusted.

[estebank]

Marking as regression because it affects stable (even though the feature that caused this can't be used, it still can be triggered).

[alexreg]

@estebank Yep, after looking into this more myself, this was my conclusion too. That said, I found out that adding

tcx.sess.span_err(span, "the `Self` constructor can only be used with \
                         tuple structs");

above the line (impl_def_id, tcx.types.err) in the instantiate_value_path fn prevents that code path from even being hit. Maybe this is enough, or maybe I should add the SelfCtor branch too?

[alexreg]

Okay, I think I've figured this out. Added a did you mean ...? label too.

[pnkfelix]

compiler triage, marking P-high.

@alexreg, did you put up a PR for this? In any case, I will assign to @alexreg since it sounds like they made progress on this.

[pnkfelix]

(hmm apparently I cannot assign to @alexreg. I'll assign to self in that case so I am reminded to either poke @alexreg or pick up the torch.)

[alexreg]

@pnkfelix Hmm, maybe because I'm not a team member? (Although I am an organisation member of course.) Anyway, the fix is in #55994 -- all ready & passing CI tests, just waiting for final review & merge.

[pnkfelix]

visiting for triage. No change necessary to meta-data (still P-high, still fixed by PR #55994, which has not yet landed). But if anyone wants to have a go at factoring out a PR focused just on just fixing the ICE, the compiler team continues to be unopposed to such effort.

[pnkfelix]

okay, in fact, this was fixed in nightly by the factored out PR #56850. The only questions are about how far to backport #56850. Leaving this open until any backporting questions are resolved.

[nagisa]

@alexreg could a backport against beta be prepared?

[nagisa]

Seems to have been backported via #57236.