ty macro arguments can be used as traits in impls

[petrochenkov]

macro_rules! m {
    ($my_type: ty) => {
        impl $my_type for u8 {} // Hmmm.

        // Not OK, this trick can't be used in any other position.
        // trait Z: $my_type {}
    }
}

trait Tr {}
m!(Tr); // OK

fn main() {}

This is a side effect of how impls are parsed - the trait in impl Trait for Type is first parsed as a type, and then reinterpreted as a type if it has appropriate syntactic form (trait syntax is a subset of type syntax).
(Same trick was used for pub(path) visibilities for some time, but then abandoned in favor of pub(in path).)

The reinterpretation trick in impl parsing can hardly be avoided, but this specific issue can be fixed because reinterpretation can be avoided if we see a ty fragment after impl.

The question is whether we should fix it or not - the issue seems benign even if it's probably unintended, an error is immediately reported if ty doesn't fit into the trait syntax.
This trick is also similar to other cases like limited use of expr fragment in range patterns (#42886), which are intended.
I would also be surprised if this was not exploited in practice.

[petrochenkov]

cc @durka because macro tricks

[durka]

I would also be surprised if this was not exploited in practice.

I agree :)

It seems kinda harmless? It would be nice to have a :trait matcher anyway... it's annoying that there's nothing you can use except $bound:ident/$($bound:tt)* if you want to output <T: $bound> or trait Tr: $bound {}.

[durka]

In the compiler:

$ rg 'impl \$[^ ]+ for' -trust src
src/libcore/slice/mod.rs
2594:            impl $traitname for $ty { }

src/test/run-pass/hygiene/trait_items.rs
20:    impl $T for () {}

These are idents though.

[durka]

In the wild: (just grepping my cargo cache for impl \$[a-zA-Z0-9_]+ for)

• $tra1t:ty https://github.com/sebcrozet/alga/blob/master/alga/src/macros.rs#L42

[ExpHP]

Anecdotally, I've done this in my own code:

(impl$par:tt [$($Trait:ty),+] for $Ty:ty as $Wrap:ident $bnd:tt)

(though I only found this one instance hiding in a couple years worth of code)

[petrochenkov]

The decision in was to accept this code and maybe pursue substitution of macro arguments as "untyped" token trees in general.