ICE in rustc::hir::map::definitions::Definitions::local_def_id when a recursive macro uses log_syntax

[tikue]

I was originally getting this ICE without using log_syntax!, and it stopped occurring after adding log_syntax!. However, when I tried to minimize the code example as much as possible, it ended up reversing and only occurring when log_syntax! was being used.

#![feature(log_syntax)]

#[macro_export]
macro_rules! ice {
    // Entry point
    ( ice; ) => {
        // Just add braces
        ice! {{ ice; }}
    };
    ( { ice; } ) => {
        log_syntax!("Move ice outside the braces");

        ice! { { } ice; }
    };
    ( { } ice; ) => {
        log_syntax!("Done");

        pub trait ThisWillIce {
            log_syntax!("Oh no!");
        }
    }
}

ice! {
    ice;
}

fn main() {
}

Backtrace:

thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:323
stack backtrace:
   1:        0x10ed9ef48 - std::sys::backtrace::tracing::imp::write::h22f199c1dbb72ba2
   2:        0x10edac77f - std::panicking::default_hook::{{closure}}::h9a389c462b6a22dd
   3:        0x10eda9c7d - std::panicking::default_hook::h852b4223c1c00c59
   4:        0x10edaa316 - std::panicking::rust_panic_with_hook::hcd9d05f53fa0dafc
   5:        0x10edaa1b4 - std::panicking::begin_panic::hf6c488cee66e7f17
   6:        0x10edaa0d2 - std::panicking::begin_panic_fmt::hb0a7126ee57cdd27
   7:        0x10edaa037 - rust_begin_unwind
   8:        0x10edea910 - core::panicking::panic_fmt::h9af671b78898cdba
   9:        0x10edea814 - core::panicking::panic::h1a2d1a6b50eaa468
  10:        0x10ba98cd7 - rustc::hir::map::definitions::Definitions::local_def_id::he14cdf9379d14d79
  11:        0x10b34541f - <rustc_resolve::build_reduced_graph::BuildReducedGraphVisitor<'a, 'b> as syntax::visit::Visitor>::visit_trait_item::hddd429568628a058
  12:        0x10b3366e1 - syntax::visit::walk_item::hdd5e3b6c2a784ebf
  13:        0x10b33da3d - rustc_resolve::macros::<impl syntax::ext::base::Resolver for rustc_resolve::Resolver<'a>>::visit_expansion::ha1f7cee58f82f9da
  14:        0x10e9d7dcb - syntax::ext::expand::MacroExpander::collect_invocations::hac509c4490fb88f2
  15:        0x10e9d5b82 - syntax::ext::expand::MacroExpander::expand::h737d7f1635448d5d
  16:        0x10e9d45a5 - syntax::ext::expand::MacroExpander::expand_crate::hd89d06b7a6333976
  17:        0x10e9df66d - syntax::ext::expand::expand_crate::h80012253cfa7f1f5
  18:        0x10ac4f88b - rustc_driver::driver::phase_2_configure_and_expand::{{closure}}::hc795707fb140075e
  19:        0x10ac07e84 - rustc_driver::driver::phase_2_configure_and_expand::h04526112c643cb41
  20:        0x10ac02862 - rustc_driver::driver::compile_input::h5b63ccd49eeeb98b
  21:        0x10ac2abb9 - rustc_driver::run_compiler::h98c7274e7cb1d11d
  22:        0x10ab688a8 - std::panicking::try::do_call::h99ed0da044e497c3
  23:        0x10edacd3a - __rust_maybe_catch_panic
  24:        0x10ab8867f - <F as alloc::boxed::FnBox<A>>::call_box::hbdd5a14cd8e33b97
  25:        0x10eda8f34 - std::sys::thread::Thread::new::thread_start::h50b05608a499d2b2
  26:     0x7fff928e799c - _pthread_body
  27:     0x7fff928e7919 - _pthread_start

[tikue]

I think somehow it just isn't expecting there to be a macro in ident position inside a trait item?

[tikue]

@jseyfried could this be related to #36573? Previously it seemed to be defining the trait item's items? Just taking a shot in the dark here.

[jseyfried]

This was caused by #36601 and was fixed in #36951.