tt-macro doesn't work

[jbclements]

I haven't finished investigating this, so I'm making an issue just so I don't forget it:

macro_rules! foo (
    ($x:tt) => {type t = ($x) int;})

foo!(~)

[jbclements]

Actually, I'm really not sure this should work. I'm nominating this for well-defined.

[jbclements]

Actually... this definitely shouldn't work in our current system. The basic issue is that a lonely sigil is not a complete "thing". The "tt" macro option is only intended for macros that expand into macro invocations. There are a number of ways around this; at the most basic level, you can insist that the user provide the sigil and the thing it's attached to. This works, but it may be unsatisfying if you want the sigil to be attached to names that are introduced by the macro. In this case, you have a couple of choices.

• use an unhygienic macro (and tell everyone what name you want to attach to the sigil, ugh)
• explicitly have three different versions of the macro, one for each sigil (bleah)
• clean up the second option by nesting one macro definition inside another one
• make sigils expand into macro invocations.

Anyhow, I would say that as of right now, at least, this is not a bug. I'm going to leave this as nominated mostly because this came up in Vancouver as something that Graydon and I both expected to work.

[huonw]

Visiting for triage: still doesn't work, nothing more to add.

[graydon]

accepted for well-defined milestone

[huonw]

You can work around this by using a dummy macro so that you can pass the tt directly to it, e.g. for the example in the issue:

#[feature(macro_rules)];

macro_rules! item { ($i: item) => { $i } }

macro_rules! foo (
    ($x:tt) => { item!(type t = $x int;) }
)

foo!(~)

fn main() {}

[jbclements]

reading this workaround makes me feel like our macro system is really broken :(.

[steveklabnik]

/cc @kmcallister

[kmcallister]

The modernized example

macro_rules! foo {
    ($x:tt) => (type t = $x<int>;)
}

foo!(Box);

gives me

/tmp/foo.rs:2:26: 2:28 error: expected type, found `an interpolated tt`
/tmp/foo.rs:2     ($x:tt) => (type t = $x<int>;)
                                       ^~

which looks like #22819.

[huonw]

#16036 notes that another hacky work-around is a nested macro invocation, which avoids needing to define/export dummy macros (although one will want to be careful about giving that internal macro a fairly unique name to avoid trampling on any other macros in scope, unfortunately 😞 ).

macro_rules! foo {
    ($x:tt) => (
        macro_rules! internal {
            () => { type t = $x<i8>; }
        }
        internal!();
    )
}

foo!(Box);

[steveklabnik]

Updated example:

macro_rules! foo {
    ($x:tt) => (type t = $x<i32>;)
}

foo!(Box);

error:

error: expected type, found `Box`
 --> <anon>:2:26
2 |>     ($x:tt) => (type t = $x<i32>;)
  |>                          ^^

[brson]

Triage: This is an ancient P-low bug but per @sanxiyn it actually comes up in the wild a lot - macro writers have to know how to do this workaround. Can this be escalated? Is there a solution somebody could mentor?

[nrc]

Discussed at lang meeting, we believe this should remain p-low since we don't know a very easy fix. It should be fixed by converting macro_rules to expand to pure tokens then parsing, rather than mixing the two steps (which we hop would be back-compat).

cc @jseyfried

[jseyfried]

Fixed in #34908.