error w/ macros that expand into macro definitions

[jbclements]

One of my expansion test cases causes an ICE:

macro_rules! g (
    ($x:ident) =>
    ({
        macro_rules! f(($y:ident)=>
                       ({
                           let $y=3;
                           $x
                       }));
        f!($x)
    }))

fn a() {
    g!(z);
}

=>

Running /usr/local/bin/rustc:
rust: task failed at 'No entry found for key: &{name: 39, ctxt: 0}', /Users/clements/rust/src/libcore/hashmap.rs:490
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug
note: try running with RUST_LOG=rustc=1,::rt::backtrace to get further details and report the results to github.com/mozilla/rust/issues
rust: task failed at 'explicit failure', /Users/clements/rust/src/librustc/rustc.rc:351
rust: domain main @0x7fabf9819210 root task failed

before going further, I must check that this happens on incoming as well as my branch....

[jbclements]

Good news... after an update, it now provides a nice error message rather than an ICE. It appears that rust does not currently support macros that expand into macro definitions.

Specifically:

Running /Users/clements/rust/build/x86_64-apple-darwin/stage2/bin/rustc:
/tmp/foo.rs:4:23: 4:24 error: unknown macro variable `y`
/tmp/foo.rs:4         macro_rules! f(($y:ident)=>
                                     ^

It appears that macro expansion insists that all identifiers preceded by a $ must be already bound to syntax terms. Fixing this will probably require a bunch of steps.

[jbclements]

update and more detail on this: the central issue here appears to be that macro invocation bodies are "too parsed, too soon." More specifically: macro invocation bodies are not parsed into ASTs, they're kept as token trees. That's good. However, the token tree language is designed to allow these token trees to contain pattern variable references. That is, pattern variables are identified when the macro is parsed into a token tree. This is bad, because you don't yet know whether a given pattern variable is a pattern variable binding or a pattern variable use. I believe the solution is to delay this decision until macro expansion time.

[emberian]

Visiting for triage; still reproduces.

[huonw]

Still an issue.

[klutzy]

Still an issue. (revision 6720977)
If $y is removed (macro_rules! f(() => ...)), rustc produces ICE: #10536

[huonw]

Now that the ICE has been fixed, is this a dupe of #6994?

[jbclements]

yes, looks that way to me.