ICE when passing a macro expression to a macro using it in an attribute in 1.18.0 and later

[ShadowNinja]

I found out that #[export_name = concat!("external_", "name")] doesn't work, so I got a bit creative and tried this (reduced example):

macro_rules! define_f {
        ($name:expr) => {
                #[export_name = $name]
                fn f() {}
        }
}
define_f!(concat!("exported_", "f"));

Which lead to this:

$ RUST_BACKTRACE=1 rustc +nightly src/lib.rs
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: run with `RUST_BACKTRACE=1` for a backtrace

thread 'rustc' panicked at 'no entry found for key', /checkout/src/libcore/option.rs:794
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:355
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:365
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:549
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:511
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:495
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:471
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:69
   9: core::option::expect_failed
             at /checkout/src/libcore/option.rs:794
  10: rustc_resolve::macros::<impl rustc_resolve::Resolver<'a>>::resolve_macro_to_def
  11: rustc_resolve::macros::<impl syntax::ext::base::Resolver for rustc_resolve::Resolver<'a>>::resolve_invoc
  12: syntax::ext::expand::MacroExpander::expand
  13: syntax::ext::expand::MacroExpander::expand_crate
  14: rustc_driver::driver::phase_2_configure_and_expand::{{closure}}
  15: rustc_driver::driver::phase_2_configure_and_expand
  16: rustc_driver::driver::compile_input
  17: rustc_driver::run_compiler

It just prints an error on stable (1.17.0):

$ RUST_BACKTRACE=1 rustc +stable src/lib.rs 
error: unexpected token: `concat!("exported_" , "f")`
 --> src/lib.rs:3:17
  |
3 |             #[export_name = $name]
  |                           ^

And of course:

$ rustc +nightly --version --verbose
rustc 1.19.0-nightly (81734e0e0 2017-05-22)
binary: rustc
commit-hash: 81734e0e06d24cf580dd5352c64d10110e4d3b7b
commit-date: 2017-05-22
host: x86_64-unknown-linux-gnu
release: 1.19.0-nightly
LLVM version: 4.0

[ben0x539]

I ran into this with declarative macros on

pub macro m($inner_str:expr) {
    #[doc = $inner_str]
    struct S;
}

m!(stringify!(foo));

[bb010g]

Panics with the same error on 1.18.0 stable now: https://is.gd/svv043

[PlasmaPower]

Now this works, but it breaks proc-macro derives on the same item (parsing fails). Should I report that bug to a different location? It sort of feels like it's rustc's fault, as it's passing the proc-macro invalid syntax.

I think it's odd that a macro can legally expand to invalid syntax...

[pierzchalski]

@PlasmaPower That sounds a rust-lang/rust problem, yes. Have you filed an issue? I'd love to see a short example of the failure.