ICE in 2018 edition: 'cannot access a scoped thread local variable without calling `set` first' #53469

Kimundi · 2018-08-18T11:01:10Z

use std::sync::mpsc::*;
struct StSt<'ast> {
    store: &'ast (),
    recv: Receiver<CmdFn>,
}
type CmdFn = Box<for<'ast> FnOnce(&mut Option<StSt<'ast>>) + Send>;
fn store_thread_new_module<'ast>(mut stst: StSt<'ast>) {
    let mut stst = Some(stst);
    while stst.is_some() {
        match stst.as_ref().unwrap().recv.recv() {
            Ok(cmd) => {
                cmd(&mut stst);
            }
            Err(_) => return,
        }
    }
}
fn main() {}

Playground link: https://play.rust-lang.org/?gist=f6c908320455219974ef86bf45be9abd&version=nightly&mode=debug&edition=2018

thread 'main' panicked at 'cannot access a scoped thread local variable without calling `set` first', /cargo/registry/src/github.com-1ecc6299db9ec823/scoped-tls-0.1.2/src/lib.rs:186: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:479
   6: std::panicking::begin_panic
   7: <scoped_tls::ScopedKey<T>>::with
   8: syntax_pos::<impl syntax_pos::span_encoding::Span>::macro_backtrace
   9: rustc_errors::emitter::EmitterWriter::fix_multispan_in_std_macros
  10: <rustc_errors::emitter::EmitterWriter as rustc_errors::emitter::Emitter>::emit
  11: rustc_errors::Handler::emit_db
  12: <rustc_errors::Handler as core::ops::drop::Drop>::drop
  13: core::ptr::drop_in_place
  14: core::ptr::drop_in_place
  15: core::ptr::drop_in_place
  16: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  17: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  18: rustc_driver::run
  19: rustc_driver::main
  20: std::rt::lang_start::{{closure}}
  21: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  22: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  23: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  24: main
  25: __libc_start_main
  26: <unknown>
query stack during panic:
end of query stack

error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https:/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.30.0-nightly (73c78734b 2018-08-05) running on x86_64-unknown-linux-gnu
note: compiler flags: -C debuginfo=2 -C incremental
note: some of the compiler flags provided by cargo are hidden

The text was updated successfully, but these errors were encountered:

earthengine · 2018-08-19T02:34:55Z

The error message is the same as #53448 (but not requiring 2018 edition, only enable #![feature(unboxed_closures)] so it is still Nightly. Maybe related.

Minimum reproducable:

fn foo(f: Box<dyn FnOnce()>) {
    f()
}
fn main() {}

So this is a known problem that we cannot call a Box<dyn FnOnce()> and the rules was get relaxed recently. But I think the work was done half way such that the MIR verification experiences unexpected code and crashes, causing this issue.

oli-obk · 2018-08-21T08:24:38Z

I think this is due to delay_span_bug being emitted way too late in the pipeline. I'll have a look

earthengine · 2018-08-21T10:37:45Z

If move the closure inside the main function,

Playground

fn main() {
    let f: Box<dyn FnOnce()> = Box::new(||{});
    f()
}

the following error occurs:

Compiling playground v0.0.1 (file:///playground)
warning[E0161]: cannot move a value of type dyn std::ops::FnOnce(): the size of dyn std::ops::FnOnce() cannot be statically determined
 --> src/main.rs:3:5
  |
3 |     f()
  |     ^
  |
  = warning: This error has been downgraded to a warning for backwards compatibility with previous releases.
          It represents potential unsoundness in your code.
          This warning will become a hard error in the future.

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `Some(([4 x i64]*:  %13 = load [4 x i64]*, [4 x i64]** %12, align 8, !dbg !39, !nonnull !4))`,
 right: `None`', librustc_codegen_llvm/mir/place.rs:100: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:479
   6: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   7: std::panicking::begin_panic_fmt
             at libstd/panicking.rs:345
   8: rustc_codegen_llvm::mir::place::PlaceRef::load
   9: rustc_codegen_llvm::mir::operand::<impl rustc_codegen_llvm::mir::FunctionCx<'a, 'll, 'tcx>>::codegen_consume
  10: rustc_codegen_llvm::mir::operand::<impl rustc_codegen_llvm::mir::FunctionCx<'a, 'll, 'tcx>>::codegen_operand
  11: rustc_codegen_llvm::mir::rvalue::<impl rustc_codegen_llvm::mir::FunctionCx<'a, 'll, 'tcx>>::codegen_rvalue
  12: rustc_codegen_llvm::mir::codegen_mir
  13: rustc_codegen_llvm::base::codegen_instance
  14: rustc_codegen_llvm::mono_item::MonoItemExt::define
  15: rustc_codegen_llvm::base::compile_codegen_unit
  16: rustc::ty::query::__query_compute::compile_codegen_unit
  17: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcx> for rustc::ty::query::queries::compile_codegen_unit<'tcx>>::compute
  18: rustc::dep_graph::graph::DepGraph::with_task_impl
  19: <rustc::ty::query::plumbing::JobOwner<'a, 'tcx, Q>>::start
  20: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::force_query_with_job
  21: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx>>::get_query
  22: rustc::ty::query::<impl rustc::ty::context::TyCtxt<'a, 'tcx, 'lcx>>::compile_codegen_unit
  23: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_utils::codegen_backend::CodegenBackend>::codegen_crate
  24: rustc::util::common::time
  25: rustc_driver::driver::phase_4_codegen
  26: rustc_driver::driver::compile_input::{{closure}}
  27: rustc::ty::context::tls::enter_context
  28: <std::thread::local::LocalKey<T>>::with
  29: rustc::ty::context::TyCtxt::create_and_enter
  30: rustc_driver::driver::compile_input
  31: rustc_driver::run_compiler_with_pool
  32: syntax::with_globals
  33: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
  34: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  35: rustc_driver::run
  36: rustc_driver::main
  37: std::rt::lang_start::{{closure}}
  38: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  39: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:102
  40: std::rt::lang_start_internal
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  41: main
  42: __libc_start_main
  43: <unknown>
query stack during panic:
#0 [compile_codegen_unit] compile_codegen_unit
end of query stack
error: internal compiler error: broken MIR in DefId(0/0:3 ~ playground[6a81]::main[0]) (NoSolution): could not prove Binder(TraitPredicate(<dyn std::ops::FnOnce() as std::marker::Sized>))
 --> src/main.rs:3:5
  |
3 |     f()
  |     ^

thread 'main' panicked at 'no errors encountered even though `delay_span_bug` issued', librustc_errors/lib.rs:314:17
stack backtrace:
   0:     0x7f2b7be5b33e - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h1410ee01a7694834
                               at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1:     0x7f2b7be340f6 - std::sys_common::backtrace::print::h1962f4c30d928b1d
                               at libstd/sys_common/backtrace.rs:71
                               at libstd/sys_common/backtrace.rs:59
   2:     0x7f2b7be31bdd - std::panicking::default_hook::{{closure}}::h66071f1a30ddacaa
                               at libstd/panicking.rs:211
   3:     0x7f2b7be31950 - std::panicking::default_hook::h8288f681d56575d2
                               at libstd/panicking.rs:227
   4:     0x7f2b78547d45 - rustc::util::common::panic_hook::hba0ca6620bd19f58
   5:     0x7f2b7be32363 - std::panicking::rust_panic_with_hook::h46fa5def146c1328
                               at libstd/panicking.rs:479
   6:     0x7f2b771d3396 - std::panicking::begin_panic::h7a665eab6b05efb6
   7:     0x7f2b771cc574 - <rustc_errors::Handler as core::ops::drop::Drop>::drop::hd437c359f6e33d6a
   8:     0x7f2b7c27f2e0 - core::ptr::drop_in_place::h914354111fa0d390
   9:     0x7f2b7c28b234 - rustc_driver::run_compiler_with_pool::h2b086979f97a3943
  10:     0x7f2b7c1e532e - syntax::with_globals::hb19a09c6ec76932b
  11:     0x7f2b7c1d4062 - <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once::h24130c7acac79061
  12:     0x7f2b7be70a19 - __rust_maybe_catch_panic
                               at libpanic_unwind/lib.rs:102
  13:     0x7f2b7c287b9c - rustc_driver::run::h89085067bde9c1b8
  14:     0x7f2b7c2955ca - rustc_driver::main::hb407a4684dbf6522
  15:     0x55e914152992 - std::rt::lang_start::{{closure}}::h8f9801ea24c231a5
  16:     0x7f2b7be31da2 - std::panicking::try::do_call::hc3bbfe344c9dd679
                               at libstd/rt.rs:59
                               at libstd/panicking.rs:310
  17:     0x7f2b7be70a19 - __rust_maybe_catch_panic
                               at libpanic_unwind/lib.rs:102
  18:     0x7f2b7be48955 - std::rt::lang_start_internal::h6831243cb445d5dc
                               at libstd/panicking.rs:289
                               at libstd/panic.rs:392
                               at libstd/rt.rs:58
  19:     0x55e914152983 - main
  20:     0x7f2b7ba3282f - __libc_start_main
  21:     0x55e914152838 - <unknown>
query stack during panic:
end of query stack
thread panicked while panicking. aborting.
error: Could not compile `playground`.

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

earthengine · 2018-08-21T12:50:02Z

@oli-obk

Please check #53526 . By adding one more syntax::with_global even the error was emitted too late it will still be contained. And a "no errors encountered even though delay_span_bug issued" shows up.

alexreg · 2018-08-22T18:10:54Z

Minimum reproducable:

fn foo(f: Box<dyn FnOnce()>) {
    f()
}
fn main() {}

This doesn't cause an ICE for me. https://play.rust-lang.org/?gist=9f0b8f5ce57015a0d70b0e3bfd208811&version=nightly&mode=debug&edition=2015

lqd · 2018-08-22T18:14:39Z

@alexreg the ICE is with the 2018 edition

Arnavion · 2018-08-22T18:36:16Z

This also happens with stage1 builds of the compiler when using it to compile crates that use custom derives. Two different copies of libsyntax_pos get used (one from stage1/bin used by the compiler and the other from stage1/lib/rustlib/$triple/lib used for macro expansion), so the scoped_tls::ScopedKey<syntax_pos::Globals>::set from the former has no effect on the scoped_tls::ScopedKey<syntax_pos::Globals>::with from the latter.

But I usually use stage2 builds (which don't have two different versions of libsyntax_pos) and only tried stage1 recently, so maybe it's always been like this and isn't an issue.

oli-obk · 2018-08-30T10:14:29Z

The ICE now shows up correctly:

error: internal compiler error: broken MIR in DefId(0/0:3 ~ playground[3845]::foo[0]) (NoSolution): could not prove Binder(TraitPredicate(<dyn std::ops::FnOnce() as std::marker::Sized>))
 --> src/main.rs:4:5
  |
4 |     f()
  |     ^

earthengine · 2018-08-31T05:09:10Z

@oli-obk

Thanks for #53624!

I updated #53448 as well.

@qnighy

Don't reduce E0161 to a warning in NLL migrate mode This error has been on stable for a while, and allowing such code cause the compile to later ICE (since we can't codegen it). Errors `box UNSIZED EXPR` with unsized locals because it's not compatible with the current evaluation order (create the box before evaluating the expressions). cc #53469 (fixes the ICE in this case) cc @qnighy

matthewjasper · 2018-09-07T18:45:44Z

Now a normal compile error. Closing.

This was referenced Aug 19, 2018

Tracking issue for FnBox() #28796

Closed

Expend syntax::with_globals coverage and allow nested calls #53526

Closed

Arnavion mentioned this issue Aug 20, 2018

ICE when existential type is exported from one crate and used in another #53443

Closed

oli-obk self-assigned this Aug 21, 2018

matthewjasper mentioned this issue Aug 21, 2018

Don't reduce E0161 to a warning in NLL migrate mode #53575

Merged

estebank added I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ A-diagnostics Area: Messages for errors, warnings, and lints WG-epoch Working group: Epoch (2018) management A-rust-2018-preview Area: The 2018 edition preview labels Aug 22, 2018

oli-obk removed their assignment Aug 30, 2018

earthengine mentioned this issue Aug 31, 2018

ICE: "broken MIR in DefId" when assigning mismatched closure to FnMut #53448

Closed

matthewjasper closed this as completed Sep 7, 2018

ExpHP mentioned this issue Oct 18, 2018

Internal compiler error: unexpected panic #55186

Closed

ghost mentioned this issue Aug 13, 2019

ICE on roman numeral macro example #63536

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ICE in 2018 edition: 'cannot access a scoped thread local variable without calling `set` first' #53469

ICE in 2018 edition: 'cannot access a scoped thread local variable without calling `set` first' #53469

Kimundi commented Aug 18, 2018 •

edited

Loading

earthengine commented Aug 19, 2018 •

edited

Loading

oli-obk commented Aug 21, 2018

earthengine commented Aug 21, 2018 •

edited

Loading

earthengine commented Aug 21, 2018

alexreg commented Aug 22, 2018

lqd commented Aug 22, 2018

Arnavion commented Aug 22, 2018

oli-obk commented Aug 30, 2018

earthengine commented Aug 31, 2018 •

edited

Loading

matthewjasper commented Sep 7, 2018

ICE in 2018 edition: 'cannot access a scoped thread local variable without calling set first' #53469

ICE in 2018 edition: 'cannot access a scoped thread local variable without calling set first' #53469

Comments

Kimundi commented Aug 18, 2018 • edited Loading

earthengine commented Aug 19, 2018 • edited Loading

oli-obk commented Aug 21, 2018

earthengine commented Aug 21, 2018 • edited Loading

earthengine commented Aug 21, 2018

alexreg commented Aug 22, 2018

lqd commented Aug 22, 2018

Arnavion commented Aug 22, 2018

oli-obk commented Aug 30, 2018

earthengine commented Aug 31, 2018 • edited Loading

matthewjasper commented Sep 7, 2018

ICE in 2018 edition: 'cannot access a scoped thread local variable without calling `set` first' #53469

ICE in 2018 edition: 'cannot access a scoped thread local variable without calling `set` first' #53469

Kimundi commented Aug 18, 2018 •

edited

Loading

earthengine commented Aug 19, 2018 •

edited

Loading

earthengine commented Aug 21, 2018 •

edited

Loading

earthengine commented Aug 31, 2018 •

edited

Loading