-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ty
macro arguments can be used as traits in impls
#46438
Comments
cc @durka because macro tricks |
I agree :) It seems kinda harmless? It would be nice to have a |
In the compiler:
These are idents though. |
In the wild: (just grepping my cargo cache for |
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) |
syntax: Rewrite parsing of impls Properly parse impls for the never type `!` Recover from missing `for` in `impl Trait for Type` Prohibit inherent default impls and default impls of auto traits (#37653 (comment), #37653 (comment)) Change wording in more diagnostics to use "auto traits" Fix some spans in diagnostics Some other minor code cleanups in the parser Disambiguate generics and qualified paths in impls (parse `impl <Type as Trait>::AssocTy { ... }`) Replace the future-compatibility hack from #38268 with actually parsing generic parameters Add a test for #46438
The decision in was to accept this code and maybe pursue substitution of macro arguments as "untyped" token trees in general. |
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 ofpub(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 afterimpl
.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.
The text was updated successfully, but these errors were encountered: