-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
macro calls emitting macro definitions resolve badly #14862
Comments
I thought we had an issue for this already but I guess not? Basically when we have multiple macros in textual scope on the item level we fail to resolve them properly in general iirc because we don't track when they shadow each other. This is basically what's happening here, so all invocations resolve to the first macro. I looked into that a year ago but couldn't come up with a solution at the time, it's a difficult problem to solve. |
Don't use inner macro in `marker_impls` Just recurse instead of having to define an inner macro to avoid the problem with expansion binders being misnumbered between the `$meta` and `$T` variables. cc `@Veykril` this should fix rust-lang/rust-analyzer#14862 since we've gotten rid of the inner macro.
Edit: Core no longer relies on this, the bug itself is still a thing though
The core library unfortunately started using the weird macro pattern where a macro invocation produces a textually scoped macro that is immediately invoked again. This works fine for r-a if the macro is only used once in a given scope, but the core library uses it several times. All consecutive uses of the inner produced macro unfortunately resolve to the very first one, meaning all impls produced by this macro end up being for
StructuralEq
.https://github.com/rust-lang/rust/blob/77fb0cd3aa276919e00397f526616c5036562ea1/library/core/src/marker.rs#L44C1-L67
The text was updated successfully, but these errors were encountered: