New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ICE 2018 edition with const fn and existential type #53096

Open
DutchGhost opened this Issue Aug 5, 2018 · 2 comments

Comments

Projects
None yet
3 participants
@DutchGhost
Copy link

DutchGhost commented Aug 5, 2018

ICE's in 2018 edition, compiles fine in 2015 edition:

#![feature(const_fn)]
#![feature(existential_type)]

existential type Foo: Fn() -> usize;

// needs to be const, for BAZR
const fn bar() -> Foo { || 0usize }

const BAZR: Foo = bar();

fn main() {

}
Backtrace:

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:105
  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:105
  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://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.30.0-nightly (3edb355b7 2018-08-03) running on x86_64-unknown-linux-gnu

note: compiler flags: -C opt-level=3 -C codegen-units=1 --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.

@DutchGhost DutchGhost changed the title ICE 2018 edition with const fn an existential type ICE 2018 edition with const fn and existential type Aug 5, 2018

@oli-obk

This comment was marked as resolved.

Copy link
Contributor

oli-obk commented Aug 6, 2018

Looks like this is a victim of "late delay_span_bug" reporting. Apparently the span interner does not exist anymore at this point.

I think

GLOBALS.with(|globals| f(&mut *globals.span_interner.lock()))
is the call that fails.

Not sure where GLOBALS is emptied.

After that has been fixed, we should be seeing the actual bug 😆

@oli-obk

This comment has been minimized.

Copy link
Contributor

oli-obk commented Jan 25, 2019

So now we can actually see the bug:

error: internal compiler error: broken MIR in DefId(0/0:5 ~ playground[d6cf]::BAZR[0]) (bb0[0]): equate_inputs_and_outputs: Foo==Foo failed with NoSolution

For a real backtrace we'd need to compile this with -Ztreat-err-as-bug

@oli-obk oli-obk self-assigned this Jan 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment