Misleading error messages when using the wrong macro fragment specifiers

[szostid]

Issue:

#[rustfmt::skip]
mod issue {
    struct SomeType<T>(std::marker::PhantomData<T>);

    macro_rules! test {
        ($ty:ty) => {
            impl<$ty,> SomeType<$ty> {}
        };
    }

    // Works fine
    impl<T,> SomeType<T> {}
    //   error: expected one of `>` or `as`, found `,`
    //   --> src\lib.rs:7:21
    //    |
    // 7  |             impl<$ty,> SomeType<$ty> {}
    //    |                     ^ expected one of `>` or `as`
    // ...
    // 12 |     test!(T);
    //    |     -------- in this macro invocation
    test!(T);

    macro_rules! test2 {
        ($ty:ty) => {
            impl<$ty> SomeType<$ty> {}
        };
    }

    // Works fine
    impl<T> SomeType<T> {}
    // error: expected `::`, found `SomeType`
    //   --> src\lib.rs:17:23
    //    |
    // 17 |             impl<$ty> SomeType<$ty> {}
    //    |                       ^^^^^^^^ expected `::`
    // ...
    // 22 |     test2!(T);
    //    |     --------- in this macro invocation
    test2!(T);
}

The macro should behave exactly like its manual expansion would; I've inlined the reported problems into the code.

Meta

The error happens in both stable and nightly toolchains, on linux and windows

rustc --version --verbose:

rustc 1.82.0 (f6e511eec 2024-10-15)
binary: rustc
commit-hash: f6e511eec7342f59a25f7c0534f1dbea00d01b14
commit-date: 2024-10-15
host: x86_64-pc-windows-msvc
release: 1.82.0
LLVM version: 19.1.1

[hanna-kruppe]

The diagnostic could be much better but this works, or rather doesn't work, "as designed". Fragment specifiers matter at least as much as the actual tokens, and $ty:ty is the wrong one for this while $ty:ident, for example works. Unfortunately, I don't know of short and accessible documentation of why this is, but off the cuff I'd summarize my intuition as: the Rust grammar doesn't expect a type there (only a name for a type variable), so a macro can't put a :type fragment there. A more detailed answer can probably be found in The Little Book Of Rust Macros.

[szostid]

You are right, for some reason I did not think about the fact that generics are, in fact, not types. Thank you very much. Either way, the error messages are very misleading (especially the second one where the compiler seems to suggests that :: should be added).

Either way, it's not up to me to decide whether this is an issue or not - feel free to close this issue