Skip to content
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: enum discriminant depends on generic arguments #64662

Closed
Patryk27 opened this issue Sep 21, 2019 · 6 comments · Fixed by #64921
Closed

ICE: enum discriminant depends on generic arguments #64662

Patryk27 opened this issue Sep 21, 2019 · 6 comments · Fixed by #64921
Assignees
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Patryk27
Copy link
Contributor

Patryk27 commented Sep 21, 2019

Following code ICEs on today's nightly (97e58c0 2019-09-20):

enum Foo {
  A = foo(),
  B = foo(), // <- error: internal compiler error: src/librustc/ty/mod.rs:2400: enum discriminant depends on generic arguments
}

const fn foo<T>() -> isize {
   0
}

What's peculiar is that no ICE is shown when the Foo enum contains only one item:

enum Foo {
  A = foo(),
}
@jonas-schievink jonas-schievink added C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-const-fn labels Sep 21, 2019
@Centril
Copy link
Contributor

Centril commented Sep 21, 2019

Backtrace:


error: internal compiler error: src/librustc/ty/mod.rs:2400: enum discriminant depends on generic arguments
 --> src/lib.rs:3:7
  |
3 |   B = foo(),
  |       ^^^^^

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:578:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:76
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:60
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1030
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1412
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:64
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:196
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:210
  10: rustc_driver::report_ice
  11: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
  12: std::panicking::begin_panic
  13: rustc_errors::Handler::span_bug
  14: rustc::util::bug::opt_span_bug_fmt::{{closure}}
  15: rustc::ty::context::tls::with_opt::{{closure}}
  16: rustc::ty::context::tls::with_context_opt
  17: rustc::ty::context::tls::with_opt
  18: rustc::util::bug::opt_span_bug_fmt
  19: rustc::util::bug::span_bug_fmt
  20: rustc::ty::AdtDef::eval_explicit_discr
  21: <rustc_typeck::collect::CollectItemTypesVisitor as rustc::hir::intravisit::Visitor>::visit_item
  22: rustc::hir::map::Map::visit_item_likes_in_module
  23: rustc_typeck::collect::collect_mod_item_types
  24: rustc::ty::query::__query_compute::collect_mod_item_types
  25: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors for rustc::ty::query::queries::collect_mod_item_types>::compute
  26: rustc::dep_graph::graph::DepGraph::with_task_impl
  27: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  28: rustc_typeck::check_crate::{{closure}}::{{closure}}
  29: rustc::util::common::time
  30: rustc_typeck::check_crate
  31: rustc_interface::passes::analysis
  32: rustc::ty::query::__query_compute::analysis
  33: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt>::get_query
  34: rustc_interface::passes::BoxedGlobalCtxt::access::{{closure}}
  35: rustc_interface::passes::create_global_ctxt::{{closure}}
  36: rustc_interface::interface::run_compiler_in_existing_thread_pool
  37: std::thread::local::LocalKey<T>::with
  38: scoped_tls::ScopedKey<T>::set
  39: syntax::with_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

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.39.0-nightly (97e58c0d3 2019-09-20) running on x86_64-unknown-linux-gnu

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

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

query stack during panic:
#0 [collect_mod_item_types] collecting item types in top-level module
#1 [analysis] running analysis passes on this crate
end of query stack
error: aborting due to 3 previous errors

Some errors have detailed explanations: E0019, E0282.
For more information about an error, try `rustc --explain E0019`.
error: could not compile `playground`.

@varkor varkor self-assigned this Sep 24, 2019
@varkor
Copy link
Member

varkor commented Sep 24, 2019

What's peculiar is that no ICE is shown when the Foo enum contains only one item:

This is because the discriminant assignment code tries to increment the discriminant of the previous variant, which was an error, and thus fails in a different way to the first. However, the code looks like it handles that case, so I'm not yet sure what's going wrong here.

Edit: I think there's some state changing inside const_eval — the discriminant assignment code seems to be working as expected. const_eval is being called with essentially identical arguments, but something about the first error is causing the second one to behave differently.

@oli-obk
Copy link
Contributor

oli-obk commented Sep 26, 2019

It's not a regression. Stable shows

   Compiling playground v0.0.1 (/playground)
error[E0282]: type annotations needed
 --> src/lib.rs:2:7
  |
2 |   A = foo(),
  |       ^^^ cannot infer type for `T`

error[E0019]: constant contains unimplemented expression type
 --> src/lib.rs:3:7
  |
3 |   B = foo(), // <- error: internal compiler error: src/librustc/ty/mod.rs:2400: enum discriminant depends on generic arguments
  |       ^^^^^

error: internal compiler error: src/librustc/ty/mod.rs:2394: enum discriminant depends on generic arguments
 --> src/lib.rs:3:7
  |
3 |   B = foo(), // <- error: internal compiler error: src/librustc/ty/mod.rs:2400: enum discriminant depends on generic arguments
  |    

I don't see how we could be keeping state. Maybe it's happening because there's no "cannot infer type for T" error on anything but the first item? So A is never evaluated, thus not causing an ICE.

@varkor
Copy link
Member

varkor commented Sep 26, 2019

Maybe it's happening because there's no "cannot infer type for T" error on anything but the first item?

Hmm, perhaps. In that case, it's simplest just to delay_span_bug instead.

@varkor
Copy link
Member

varkor commented Sep 26, 2019

This no longer ICEs on nightly, though it does ICE on beta. We now get type inference errors on both variants.

@varkor varkor closed this as completed Sep 26, 2019
@varkor
Copy link
Member

varkor commented Sep 26, 2019

Reopening, as we should have a test.

@varkor varkor reopened this Sep 26, 2019
@varkor varkor added E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. and removed I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ I-nominated labels Sep 26, 2019
tmandry added a commit to tmandry/rust that referenced this issue Sep 30, 2019
@bors bors closed this as completed in e9d2879 Oct 1, 2019
@RalfJung RalfJung added the A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) label Dec 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) C-bug Category: This is a bug. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants