Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Improve the diagnostics for unused generic params in ty aliases & permit bivariant but constrained params in LTAs #120556
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
Improve the diagnostics for unused generic params in ty aliases & permit bivariant but constrained params in LTAs #120556
Changes from all commits
02320b5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't want to deal with this right now but I can try to do so if you'd like me to. I think it'll be a bit nasty to implement though. Consider a hypothetical set of predicates like
[<A as TraitA>, <B as TraitB>, /*elab*/<A as Sized>]
(note: we need to merge the spans of the 0th and the 2nd predicate).Maybe it's actually not that ugly to implement, I just haven't spent any time to think about this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why does it rely on that? the spans differ, so both elaborated and user-written would end up in the hash set
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦 it's a hashmap and this collect relies on the hash map impl overwriting with follow up items of the same key
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems fine to rely on this, there are tests after all
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm no longer extracting the
Symbol
from theIdent
viaparam.name.ident().name
since theDisplay
impl forIdent
accounts for escaping viar#
. This way, we properly displayr#if
intype T<r#if> = ();
asr#if
instead ofif
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could add extra code for skipping this error entirely by delaying a bug on
_
when checking the “usedness”. Not sure if it'd be worth it though.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be very hard to track the
expected identifier, found reserved identifier
error all the way into the type system. We'd probably have to add aGenericParamDefKind::Error
to do that. May be worth exploring, but not in this PR