Debug assertion failure in hir/mod/map:956

[tmandry]

When building a single target in Fuchsia with debug assertions enabled, there are a bunch of repeated panic messages like this. All of them occur when type-checking the impl item outputted by a macro on this line of code. The failing assertion is this one in opt_span:

rust/compiler/rustc_middle/src/hir/map/mod.rs

Line 956 in 4c5ce1f

debug_assert_eq!(span.ctxt(), self.span_with_body(hir_id).ctxt());

thread 'rustc' panicked at compiler/rustc_middle/src/hir/map/mod.rs:956:9:
assertion `left == right` failed
  left: #104
 right: #105
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed::<rustc_span::hygiene::SyntaxContext, rustc_span::hygiene::SyntaxContext>
   4: <rustc_middle::hir::map::Map>::opt_span
   5: <rustc_middle::hir::map::Map>::span
   6: <rustc_hir_typeck::fn_ctxt::FnCtxt>::supplied_sig_of_closure
   7: <rustc_hir_typeck::fn_ctxt::FnCtxt>::sig_of_closure_no_expectation
   8: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_closure
   9: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_expr_closure
  10: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_expr_kind
  11: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_expr_with_expectation_and_args
  12: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_expr_with_expectation
  13: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_call
  14: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_expr_kind
  15: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_expr_with_expectation_and_args
  16: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_expr_with_expectation
  17: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_decl_initializer
  18: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_decl
  19: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_stmt
  20: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_block_with_expected
  21: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_expr_kind
  22: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_expr_with_expectation_and_args
  23: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_expr_with_expectation
  24: <rustc_hir_typeck::fn_ctxt::FnCtxt>::check_return_expr
  25: rustc_hir_typeck::check::check_fn
  26: rustc_hir_typeck::typeck
      [... omitted 2 frames ...]
  27: <rustc_middle::hir::map::Map>::par_body_owners::<rustc_hir_analysis::check_crate::{closure#7}>::{closure#0}
  28: rustc_hir_analysis::check_crate
  29: rustc_interface::passes::analysis
      [... omitted 2 frames ...]
  30: <rustc_middle::ty::context::GlobalCtxt>::enter::<rustc_driver_impl::run_compiler::{closure#0}::{closure#0}::{closure#3}, core::result::Result<(), rustc_span::ErrorGuaranteed>>
  31: <rustc_interface::interface::Compiler>::enter::<rustc_driver_impl::run_compiler::{closure#0}::{closure#0}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>>
  32: rustc_span::set_source_map::<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_interface::interface::run_compiler<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#0}>::{closure#0}::{closure#0}>
  33: <scoped_tls::ScopedKey<rustc_span::SessionGlobals>>::set::<rustc_interface::util::run_in_thread_pool_with_globals<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#0}>::{closure#0}, core::result::Result<(), rustc_span::ErrorGuaranteed>>::{closure#0}, core::result::Result<(), rustc_span::ErrorGuaranteed>>
  34: rustc_span::create_session_globals_then::<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_interface::util::run_in_thread_pool_with_globals<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#0}>::{closure#0}, core::result::Result<(), rustc_span::ErrorGuaranteed>>::{closure#0}>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: please attach the file at `/code/fuchsia/out/default/rustc-ice-2024-01-04T22_07_58-3292635.txt` to your bug report

note: compiler flags: --crate-type rlib -Z dep-info-omit-d-target -C linker=../../prebuilt/third_party/clang/linux-x64/bin/lld -C link-arg=--sysroot=gen/zircon/public/sysroot/cpp -C link-arg=-L../../prebuilt/third_party/clang/linux-x64/bin/../lib/x86_64-unknown-fuchsia/noexcept -C link-arg=-L../../prebuilt/third_party/clang/linux-x64/lib/clang/18/lib/x86_64-unknown-fuchsia -C link-arg=--pack-dyn-relocs=relr -C link-arg=-dynamic-linker=ld.so.1 -C link-arg=--icf=all -C link-arg=-zrel -Z remap-cwd-prefix=. -C force-frame-pointers -C opt-level=0 -C debuginfo=2 -C link-arg=--compress-debug-sections=zstd -C debug-assertions=yes -Z allow-features= -C prefer-dynamic -C link-args=-zstack-size=0x200000 -C panic=abort -C force-unwind-tables=yes -Z panic_abort_tests -C symbol-mangling-version=v0

query stack during panic:
#0 [typeck] type-checking `args::<impl at ../../src/performance/lib/fxt/rust/src/header.rs:60:9: 60:19>::new`
#1 [analysis] running analysis passes on this crate
end of query stack

rustc-ice-2024-01-04T22_07_58-3292635.txt

I do not have a minimized reproducer yet.

[tmandry]

cargo expand output:

https://gist.github.com/tmandry/c8bd5a6a55bee3aa2e5c875d5779f5ab

[tmandry]

Function being type checked in the first panic: (gist)

fn new(bits: u64) -> Result<Self, crate::ParseError> {
    let header = Self(bits);
    let res: Result<(), crate::ParseError> = (|_h| Ok(()))(&header);
    res?;
    Ok(header)
}

next to unexpanded parts of the macro:

    (
        $name:ident (max_size_bit: $upper_size_bit:literal) ($size_ty:ty) $(($header_ty:expr))? {
            $($field_ty:ty, $getter:ident: $start_bit:literal, $end_bit:literal;)*
        } => |$header:ident $(: $header_arg_ty:ty)?| $verify:expr
    ) => {

// [...]

            fn new(bits: u64) -> Result<Self, crate::ParseError> {
                let header = Self(bits);

                $(if header.raw_type() != $header_ty {
                    return Err(crate::ParseError::WrongType {
                        context: stringify!($name),
                        expected: $header_ty,
                        observed: header.raw_type(),
                    });
                })?

                // Run invoker-defined verification and return if it's an error.
                let res: Result<(), crate::ParseError> = (|$header $(: $header_arg_ty)?| $verify)(&header);
                res?;

                Ok(header)
            }

// [...]

    }

[compiler-errors]

Do you have info about the invocation of the macro?

[tmandry]

There's one here:

trace_header! {
    EventHeader (EVENT_RECORD_TYPE) {
        u8, event_type: 16, 19;
        u8, num_args: 20, 23;
        u8, thread_ref: 24, 31;
        u16, category_ref: 32, 47;
        u16, name_ref: 48, 63;
    }
}

the corresponding expansion is here:

fn new(bits: u64) -> Result<Self, crate::ParseError> {
    let header = Self(bits);
    if header.raw_type() != EVENT_RECORD_TYPE {
        return Err(crate::ParseError::WrongType {
            context: "EventHeader",
            expected: EVENT_RECORD_TYPE,
            observed: header.raw_type(),
        });
    }
    let res: Result<(), crate::ParseError> = (|_h| Ok(()))(&header);
    res?;
    Ok(header)
}

The original one I posted is here, inside some ooey nested macro goodness. Looks like every invocation there leads to the ICE.

[compiler-errors]

Is that first invocation (EventHeader) you shared actually ICEing? Because if not, then I think it's due to nested macro invocations.

[tmandry]

@compiler-errors Yeah it is ICEing. In the build log attached to the description there's an ICE in the event module.