Compiler panic - $crate in proc macro

[laurmaedje]

The following code uses the idea from proc-macro-hack to custom derive on a struct, return a macro from that derive and then invoke the macro.
I was trying what $crate would do in this context and expected that my code would just break.

But instead the compiler broke:

thread 'rustc' panicked at 'no entry found for key', libcore/option.rs:917:5
note: the compiler unexpectedly panicked. this is a bug.

This script reproduces the issue:

#!/bin/bash

cargo new --bin bug
cd bug

# proc macro
cargo new bug-macro
cat >> bug-macro/Cargo.toml <<-'EOF'
    quote = "0.4"

    [lib]
    proc-macro = true
EOF

cat > bug-macro/src/lib.rs <<-'EOF'
    #[macro_use]
    extern crate quote;
    extern crate proc_macro;
    use proc_macro::TokenStream;

    #[proc_macro_derive(Test)]
    pub fn test_derive(_: TokenStream) -> TokenStream {
        (quote! {
            macro_rules! result {
                () => ($crate::Data)         // <-- this is the problem
            }
        }).into()
    }
EOF

# binary crate
cat >> Cargo.toml <<-'EOF'
    bug-macro = { path = "bug-macro" }
EOF

cat > src/main.rs <<-'EOF'
    #[macro_use]
    extern crate bug_macro;

    struct Data;

    fn main() {
        #[derive(Test)]
        struct Test;
        result!()
    }
EOF

cargo build

Meta

rustc 1.25.0-nightly (b1f8e6f 2018-02-22)
binary: rustc
commit-hash: b1f8e6f
commit-date: 2018-02-22
host: x86_64-unknown-linux-gnu
release: 1.25.0-nightly
LLVM version: 6.0

[dtolnay]

Backtrace on rustc 1.27.0-nightly (48fa6f9 2018-04-05):

   9: core::option::expect_failed
             at libcore/option.rs:916
  10: rustc_resolve::build_reduced_graph::<impl rustc_resolve::Resolver<'a>>::macro_def_scope
  11: rustc_resolve::Resolver::resolve_crate_root
  12: rustc_resolve::Resolver::resolve_path
  13: rustc_resolve::Resolver::smart_resolve_path_fragment
  14: rustc_resolve::Resolver::resolve_expr
  15: <rustc_resolve::Resolver<'a> as syntax::visit::Visitor<'tcx>>::visit_block
  16: <rustc_resolve::Resolver<'a> as syntax::visit::Visitor<'tcx>>::visit_fn
  17: syntax::visit::walk_item
  18: rustc_resolve::Resolver::resolve_item
  19: rustc_resolve::Resolver::resolve_crate
  20: rustc::util::common::time
  21: rustc_driver::driver::phase_2_configure_and_expand
  22: rustc_driver::driver::compile_input
  23: rustc_driver::run_compiler_impl
  24: syntax::with_globals
  25: rustc_driver::run
  26: rustc_driver::main

[nikomatsakis]

Is this truly a regression? It seems like it's "just an ICE"? If it is a regression, can we bisect?

[pnkfelix]

self-assigning to make sure we get answers to @nikomatsakis questions above.

[pnkfelix]

triage: P-high

the priority reflects my interest in getting answers to those questins. but if its "just an ICE" and not much esle (and not a true regression) then we can readily downgrade to P-medium.

[dtolnay]

Yes I believe this is a regression. If you change the result!() in the repro script to let _ = result!(); to make it type check, then this compiles with 1.23.0 but ICEs since 1.24.0.

But this is a macro_rules emitted by a custom derive which seems like a rehash of #46478, in which we decided we did not mean to support this anyway.

[alexcrichton]

Removing this from the 1.27 milestone and the 1.27 regressions as this looks to be a stable -> stable regression according to @dtolnay's comment

[nikomatsakis]

Discussing in @rust-lang/compiler meeting. If indeed this is a rehash of #46478, then it seems we should close it.