ICE: called Option::unwrap() on a None value', compiler\rustc_hir\src\definitions.rs:452:14

[Crazytieguy]

Code

https://github.com/Crazytieguy/bevy_chess/tree/64592ffea7a46662b44588253eee050b8cdf6f6d

Meta

rustc --version --verbose:

rustc 1.58.0-nightly (db062de72 2021-11-01)
binary: rustc
commit-hash: db062de72b0a064f45b6f86894cbdc7c0ec68844
commit-date: 2021-11-01
host: x86_64-pc-windows-msvc
release: 1.58.0-nightly
LLVM version: 13.0.0

Error output

error: internal compiler error: unexpected panic

note: compiler flags: -Z share-generics=y -C embed-bitcode=no -C debuginfo=1 -C linker=rust-lld.exe -C incremental --crate-type bin

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

Backtrace

thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/db062de72b0a064f45b6f86894cbdc7c0ec68844\compiler\rustc_hir\src\definitions.rs:452:14

[jyn514]

@Crazytieguy can you still reproduce the crash if you remove -Z share-generics?

[Crazytieguy]

@jyn514 If I remove -Z share-generics it compiles :)

[jyn514]

cc @davidtwco

[davidtwco]

cc @davidtwco

-Zshare-generics isn’t polymorphization. It’s possible that polymorphization’s changes (despite being disabled) are related to this, but I don’t see any reason to suspect so from this issue.

[jyn514]

Oh oops, sorry. Never mind then.

[michaelwoerister]

This looks suspiciously like an incremental compilation bug. @Crazytieguy, do you happen to know which part of the code you modified before the ICE occurred?

[Crazytieguy]

@michaelwoerister The change has to be in here Crazytieguy/bevy_chess@64592ff

If I remember correctly, the last thing I did was replace PlayerTurn with GameStatus. camera.rs was complete and working properly before, so it's not that.

[FranchuFranchu]

I experienced the same ICE after writing this commit. The last file I had worked on was src/trap_future_executor.rs and some changes in src/syscall.rs. However, I don't use -Zshare-generics. I do however use a large amount of unstable features so that might be the main risk factor in my case.

[cjgillot]

-Zshare-generics is very probably a red herring. This looks like a regular (so to speak) incremental compilation bug. Changing the value of share-generics triggered a compilation with a clean incr. comp. cache.

[jaw-sh]

I encountered this issue when adding try_join! to my code, to reduce synchronous queries in a project i'm building. I would share the entire thing if I thought it would help, but I haven't been able to reproduce it.

#[get("/threads/{thread_id}/")]
pub async fn view_thread(
    path: web::Path<(i32,)>,
    data: web::Data<MainData<'static>>,
) -> Result<HttpResponse, Error> {
    use crate::orm::threads;
    use futures::try_join;

    let thread = Thread::find_by_id(path.into_inner().0)
        .one(&data.pool)
        .await
        .map_err(|_| error::ErrorInternalServerError("Could not look up thread."))?
        .ok_or_else(|| error::ErrorNotFound("Thread not found."))?;

    // Update thread to include views.
    let tfuture = threads::Entity::update_many()
        .col_expr(
            threads::Column::ViewCount,
            Expr::value(thread.view_count + 1),
        )
        .filter(threads::Column::Id.eq(thread.id))
        .exec(&data.pool)
        //.await
        .map_err(|err| error::ErrorInternalServerError(err))?;

    // Load posts, their ugc associations, and their living revision.
    let pfuture = Post::find()
        .find_also_linked(super::orm::posts::PostToUgcRevision)
        .filter(super::orm::posts::Column::ThreadId.eq(thread.id))
        .all(&data.pool)
        //.await
        .map_err(|_| error::ErrorInternalServerError("Could not find posts for this thread."))?;

    // Multi-thread drifting!
    let (presults, _) =
        try_join!(pfuture, tfuture).map_err(|err| error::ErrorInternalServerError(err))?;

    let mut posts = Vec::new();
    for (p, u) in &presults {
        posts.push(PostForTemplate::from_orm(&p, &u));
    }

    Ok(HttpResponse::Ok().body(ThreadTemplate { thread, posts }.render().unwrap()))
}

I tried recreating it in a small project as well but I had no luck. It's actix-web with SeaQL.

I encountered the compiler error after adding try_join! in a similar state to as it is presented. The issue did not go away and did not compile until I also used future::futures::TryFutureExt, at which point the compiler error went away and the code worked without issue. I've not been able to undo my changes and recreate the error even in the original code.

Full backtrace:

thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/compiler/rustc_hir/src/definitions.rs:452:14
stack backtrace:
   0:     0x7f99b00e3a9c - std::backtrace_rs::backtrace::libunwind::trace::hf6a6dfd7da937cb0
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:     0x7f99b00e3a9c - std::backtrace_rs::backtrace::trace_unsynchronized::hc596a19e4891f7f3
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x7f99b00e3a9c - std::sys_common::backtrace::_print_fmt::hb16700db31584325
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x7f99b00e3a9c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h231c4190cfa75162
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x7f99b0140fdc - core::fmt::write::h2a1462b5f8eea807
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/fmt/mod.rs:1163:17
   5:     0x7f99b00d3c05 - std::io::Write::write_fmt::h71ddfebc68685972
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/io/mod.rs:1696:15
   6:     0x7f99b00e6f60 - std::sys_common::backtrace::_print::hcc197d4bebf2b369
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x7f99b00e6f60 - std::sys_common::backtrace::print::h335a66af06738c7c
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x7f99b00e6f60 - std::panicking::default_hook::{{closure}}::h6fac9ac9c8b79e52
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:210:50
   9:     0x7f99b00e6b15 - std::panicking::default_hook::h341c1030c6a1161b
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:227:9
  10:     0x7f99b08d32b1 - rustc_driver::DEFAULT_HOOK::{{closure}}::{{closure}}::h932547f60770f26a
  11:     0x7f999814c273 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h9ecfe8ad3730f2bf
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/alloc/src/boxed.rs:1705:9
  12:     0x7f99981cb28d - proc_macro::bridge::client::<impl proc_macro::bridge::Bridge>::enter::{{closure}}::{{closure}}::heed0aea2b0a83910
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/proc_macro/src/bridge/client.rs:320:21
  13:     0x7f99b00e7779 - std::panicking::rust_panic_with_hook::h50680ff4b44510c6
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:628:17
  14:     0x7f99b00e7202 - std::panicking::begin_panic_handler::{{closure}}::h9371c0fbb1e8465a
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:519:13
  15:     0x7f99b00e3f44 - std::sys_common::backtrace::__rust_end_short_backtrace::h9b3efa22a5768c0f
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/sys_common/backtrace.rs:139:18
  16:     0x7f99b00e7199 - rust_begin_unwind
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:517:5
  17:     0x7f99b00ab441 - core::panicking::panic_fmt::h23b9203e89cc61cf
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/panicking.rs:100:14
  18:     0x7f99b00ab38d - core::panicking::panic::h0ba7146865b2f9d6
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/panicking.rs:50:5
  19:     0x7f99b20d6b47 - <rustc_query_impl::on_disk_cache::OnDiskCache as rustc_middle::ty::context::OnDiskCache>::def_path_hash_to_def_id::hb925ab58899dddff
  20:     0x7f99b2442b21 - rustc_middle::dep_graph::dep_node::<impl rustc_query_system::dep_graph::dep_node::DepNodeParams<rustc_middle::ty::context::TyCtxt> for rustc_span::def_id::LocalDefId>::recover::h2e76aa40aab4da19
  21:     0x7f99b2acd52c - rustc_query_impl::query_callbacks::hir_owner::force_from_dep_node::hc7fd02f51ac51090
  22:     0x7f99b20c1d6a - rustc_query_system::dep_graph::graph::DepGraph<K>::try_mark_previous_green::h14b50df9818693f3
  23:     0x7f99b20c1d41 - rustc_query_system::dep_graph::graph::DepGraph<K>::try_mark_previous_green::h14b50df9818693f3
  24:     0x7f99b20c1d41 - rustc_query_system::dep_graph::graph::DepGraph<K>::try_mark_previous_green::h14b50df9818693f3
  25:     0x7f99b20c1d41 - rustc_query_system::dep_graph::graph::DepGraph<K>::try_mark_previous_green::h14b50df9818693f3
  26:     0x7f99b2020234 - rustc_query_system::query::plumbing::ensure_must_run::h5874d260d5ffefca
  27:     0x7f99b2adb430 - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::coherent_trait::hef06870853770eff
  28:     0x7f99b1c9abf6 - rustc_session::session::Session::track_errors::hd7a6334bb75371c9
  29:     0x7f99b277e448 - rustc_typeck::check_crate::h6215961d94aab927
  30:     0x7f99b24dd0a0 - rustc_interface::passes::analysis::h9fda1a8ae44d53e7
  31:     0x7f99b2af73cf - rustc_query_system::dep_graph::graph::DepGraph<K>::with_task::h26e86d963a73dec8
  32:     0x7f99b2a9c609 - rustc_data_structures::stack::ensure_sufficient_stack::h135baf7277c4d193
  33:     0x7f99b29c0a7b - rustc_query_system::query::plumbing::try_execute_query::h0bf7639d3f58bfbd
  34:     0x7f99b2ad9232 - <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis::ha2144cf05b40d10d
  35:     0x7f99b24d1ca9 - rustc_interface::passes::QueryContext::enter::h0523b23606206a0b
  36:     0x7f99b24b8977 - rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter::hf84cd18c24bd5171
  37:     0x7f99b24a60ee - rustc_span::with_source_map::h6ab8a240e103b5b9
  38:     0x7f99b24b82ac - scoped_tls::ScopedKey<T>::set::hd1fbd64c6f645895
  39:     0x7f99b24a6ef5 - std::sys_common::backtrace::__rust_begin_short_backtrace::h0a1328c9fa7f7448
  40:     0x7f99b24d2962 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h4ea1ced06d6b3e97
  41:     0x7f99b00f2933 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h7bd677a5dc988be6
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/alloc/src/boxed.rs:1691:9
  42:     0x7f99b00f2933 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h7b1c1ba11c4db785
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/alloc/src/boxed.rs:1691:9
  43:     0x7f99b00f2933 - std::sys::unix::thread::Thread::new::thread_start::h9c58c0d12d84e854
                               at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/sys/unix/thread.rs:106:17
  44:     0x7f99b0007259 - start_thread
  45:     0x7f99aff1c5e3 - __GI___clone
  46:                0x0 - <unknown>

error: internal compiler error: unexpected panic

Be aware I'm a new developer and I have no idea what I'm doing.

rustc 1.57.0 (f1edd04 2021-11-29), Manjaro

[oxalica]

Also encountered this with 1.57.0 stable in my private project.
Do a cargo clean and rerun cargo clippy will fix it. Maybe it's related some changes, not some static code.

[cjgillot]

This is a bug in incremental compilation, which makes it very difficult to debug and dependent on the changes between a rebuild and the next. And indeed, the "easy" fix is cargo clean.

[nicolodavis]

Perhaps we should disable incremental compilation when compiling with a version of rustc that's at least a minor version more recent than the version that was used for the previous build?

[BGR360]

Hopefully fixed by #91919.

[Aaron1011]

This should be fixed on the latest nightly by #91924. Note that PR #91919 just adds in a check to prevent new instances of this type of issue from being added to the rustc codebase.