Stop inserting redundant parenthesis around desugared match expressions #16102
Conversation
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
rustbot
added
the
S-waiting-on-review
Collaborator
|
r? @Alexendoo rustbot has assigned @Alexendoo. Use |
|
Lintcheck changes for 466646f
This comment will be updated if you push new changes |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Currently the
suggutility treats allExprKind::Matchexpressions as potentially needing brackets, and therefore many lints will add parenthesis around them. However this includes desugared match expressions like the?and.awaitoperators.In this PR I have updated the utility to only treat match expressions which include a code block as needing parenthesis, as the other types have similar precedence rules and expectations to things like member access and I think can be treated like as such.
While this change is small on paper it touches a large amount of code due to changing a cross cutting concern, I am happy to add additional tests if we think it is needed, but I wanted to get a feel for if this is even a sensible change to be doing and what the expectations were around the level of testing needed before investing more time into it.
Regarding not putting a specific lint in the changelog, determining all the lints this could possibly effect would be possible but take some time, and I wonder if it would be a bit too noisy in the changelog. Open to suggestions about how best to address that.
fixes #16045
changelog: stop inserting unnecessary brackets around
x?andx.awaitexpressions in suggestions