Generic/where clause bounds generated by a macro fail to parse even when syntactically correct

[abonander]

There is no fragment specifier to make $genericbnd work in the following macro:

(playpen)

macro_rules! takes_fn {
    (fn $fnname:ident <$generic:ident : $genericbnd:ty> () {}) => (
        fn $fnname <$generic : $genericbnd > () {}
    )
}

takes_fn! {
    fn foo<T: ToString>() {}
}

The parser assumes the $generic token encompasses the whole type and fails to parse the actual bound:

error: expected one of `,`, `=`, `>`, or `?`, found `ToString`
 --> <anon>:3:32
  |
3 |         fn $fnname <$generic : $genericbnd > () {}
  |                                ^^^^^^^^^^^

This similarly fails with where clauses:

(playpen)

macro_rules! takes_fn {
    (fn $fnname:ident <$generic:ident> () where $whereid:path : $wherebnd:ty {}) => (
        fn $fnname <$generic> () where $whereid : $wherebnd {}
    )
}

takes_fn! {
    fn foo<T>() where T: ToString {}
}

Which yields the following error:

error: each predicate in a `where` clause must have at least one bound in it
 --> <anon>:3:40
  |
3 |         fn $fnname <$generic> () where $whereid : $wherebnd {}
  |                                        ^^^^^^^^^^

error: expected one of `,`, `?`, or `{`, found `ToString`
 --> <anon>:3:51
  |
3 |         fn $fnname <$generic> () where $whereid : $wherebnd {}
  |              

This makes it very difficult to create macros which wrap the generation of an item containing generic bounds or where clauses. It would be nice to just use tt for the generics but > is not a valid closing delimiter for stopping a tt fragment at the end of the generics clause, and neither is { for stopping it at the end of a where clause. This can be done if you modify the Rust grammar to wrap generics and where clauses in parenthesis or curly brackets (because tt will not eat a closing parenthesis or curly bracket), but this is ugly and unintuitive.

[durka]

The problem is that a trait bound (right side of the :) isn't a type, even though it looks like one, and by the time it's parsed that way it's too late. In fact, there's no fragment specifier for it. The only choice is a tt-sequence, but then you need to use a recursive macro. See also parse-generics.

[bluss]

See also rust-lang/rfcs/pull/1583, it points out macros 1.1 to solve this (which I think didn't come to pass).

[abonander]

Closed by #38279! Well done @KalitaAlexey.

[KalitaAlexey]

@abonander, I am glad you are happy)