-
Notifications
You must be signed in to change notification settings - Fork 1.8k
fix ignored_unit_patterns: include refs in the suggestion
#15578
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
Open
ada4a
wants to merge
1
commit into
rust-lang:master
Choose a base branch
from
ada4a:ignored-unit-patterns
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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.
Hm, seems like matching
()is also valid and the&s are not required. Does that also work (without compiler error) in closures?Uh oh!
There was an error while loading. Please reload this page.
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.
Well it depends. You're right that the refs are not required in match arms, and they are not required in closures most of the time.
But as #15187 shows, it stops working when you try casting the closure toimpl Fn(&()), for example.The solution I tried first was to eliminate all the cases where we know the refs aren't needed (e.g. all match arm patterns),
but it now looks like the only case where they are needed are the situations where a closure accepting&()later gets coerced tofn(&())/impl Fn*(&()). Therefore, we could theoretically try catching only those cases, but that will probably require writing some kind of a HIR visitor, and those things are kind of intimidating to me tbh...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.
Imo the first solution (don't add refs when suggesting for match arms, but do add them for all closure params) is a good balance of simplicity and correctness
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.
Well it's not even that!
casting/coercing the closure to both an
fnand aFn*trait object works actually just finechanging anything about the issue's reproducer, like:
LifetimeBoundtype aliasdynwithimplin the type aliaseither stops the thing from compiling, or makes it so that
()starts getting accepted as wellI guess I'm not well-versed enough in the type system shenanigans to pinpoint the combination of factors that makes this exact expression require
&()instead of(). If you have any ideas, let me know (and let me know if you know a way I could test for said factors) -- otherwise, we might want to just close the issue as WONTFIX, given how specific it is?..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.
@flip1995 friendly ping