Closed
Description
Hi, I'm not sure if this has been reported or is known at all. If it has feel free to close it out.
This example:
#![feature(nll)]
struct Bar;
struct Foo<'s> {
bar: &'s mut Bar,
}
impl Foo<'_> {
fn new(bar: &mut Bar) -> Self {
Foo { bar }
}
}
causes an ICE on rustc 1.31.0-nightly (4bd4e41 2018-10-25)
This is the error I'm getting, backtrace included:
error: internal compiler error: librustc/hir/map/mod.rs:815: expected expr, found method new in Foo::new (id=19) [3/9508]
thread 'main' panicked at 'Box<Any>', librustc_errors/lib.rs:600:9
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at libstd/sys_common/backtrace.rs:71
at libstd/sys_common/backtrace.rs:59
2: std::panicking::default_hook::{{closure}}
at libstd/panicking.rs:211
3: std::panicking::default_hook
at libstd/panicking.rs:227
4: rustc::util::common::panic_hook
5: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:480
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::map::Map::expect_expr
15: rustc_mir::borrow_check::nll::region_infer::error_reporting::region_name::<impl rustc_mir::borrow_check::nll::region_infer::RegionInferenceContext<'tcx>>::give_region_a_name
16: rustc_mir::borrow_check::nll::region_infer::error_reporting::<impl rustc_mir::borrow_check::nll::region_infer::RegionInferenceContext<'tcx>>::report_general_error
17: rustc_mir::borrow_check::nll::region_infer::RegionInferenceContext::solve_inner
18: rustc::util::common::time
19: rustc_mir::borrow_check::nll::region_infer::RegionInferenceContext::solve
20: rustc_mir::borrow_check::nll::compute_regions
21: rustc_mir::borrow_check::do_mir_borrowck
22: rustc::ty::context::tls::with_related_context
23: rustc::infer::InferCtxtBuilder::enter
24: rustc_mir::borrow_check::mir_borrowck
25: rustc::ty::query::__query_compute::mir_borrowck
26: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::mir_borrowck<'tcx>>::compute
27: rustc::dep_graph::graph::DepGraph::with_task_impl
28: <rustc::ty::query::plumbing::JobOwner<'a, 'tcx, Q>>::start
29: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
30: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
31: rustc::ty::query::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::mir_borrowck
32: rustc::ty::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::par_body_owners
33: rustc::util::common::time
34: rustc::ty::context::tls::enter_context
35: <std::thread::local::LocalKey<T>>::with
36: rustc::ty::context::TyCtxt::create_and_enter
37: rustc_driver::driver::compile_input
38: rustc_driver::run_compiler_with_pool
39: rustc_driver::driver::spawn_thread_pool
40: rustc_driver::run_compiler
41: <scoped_tls::ScopedKey<T>>::set
42: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
43: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:102
44: rustc_driver::run
45: rustc_driver::main
46: std::rt::lang_start::{{closure}}
47: std::panicking::try::do_call
at libstd/rt.rs:59
at libstd/panicking.rs:310
48: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:102
49: std::rt::lang_start_internal
at libstd/panicking.rs:289
at libstd/panic.rs:392
at libstd/rt.rs:58
50: main
51: __libc_start_main
52: <unknown>
query stack during panic:
#0 [mir_borrowck] processing `Foo::new`
end of query stack
Activity
pnkfelix commentedon Nov 6, 2018
Okay, the good news here is that I only see this ICE with
#![feature(nll)]
; it does not arise with the NLL migration mode being deployed as part of the 2018 edition. See e.g. this play.pnkfelix commentedon Nov 6, 2018
The code in question is rejected by AST-borrowck. It looks like it is being rejected by NLL as well, and the problem is that we hit an error when trying to generated our diagnostic.
Therefore, I'm going to tag this as NLL-sound (since this seems like a case where we want to reject the code in question) and NLL-diagnostics (since the ICE itself is stemming from diagnostics code).
And I think I'm going to make it P-high, because 1. ICE's are super annoying and 2. I bet its not hard to fix.
But I'm not going to tag it with the Release milestone, because its not something we need to worry about backporting to the beta channel (because it does not arise with NLL migration mode).
pnkfelix commentedon Nov 6, 2018
actually I'll remove NLL-sound; this isn't a case where NLL is incorrectly accepting the code. Its just incorrectly behaving while generating the diagnostics.
[-]ICE with NLL and elided lifetimes[/-][+]ICE with #![feature(nll)] and elided lifetimes[/+]