Refactor useless_vec lint
#14503
Open
Refactor useless_vec lint
#14503
+157
−87
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
y21
force-pushed
the
useless_vec_rework
branch
2 times, most recently
from
e6ccc88 to
834da8f
Compare
|
Looks like this also fixes the bug in #14531 indirectly (previously it hardcoded I added a test for this in the second commit. |
| Applicability::Unspecified | ||
| } else { | ||
| *applicability | ||
| Applicability::MachineApplicable |
There was a problem hiding this comment.
Nit: getting the snippet is fallible (or .unwrap() should have been used instead of .unwrap_or_default() in SuggestedType::snippet()). Shouldn't the applicability be recorded in VecState as well?
|
Rerolling as I'll be AFK for a while. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 there's an "implicit" invariant in this lint's code, which has been bugging me for a while (but especially so because I recently wanted to extend this lint): when we see a
vec![]expression that we can't suggest changing to an array because of surrounding expressions (e.g. it's passed to a function that requires aVec), we must insert that into thisself.span_to_lint_mapmap withNone.See FP issue #11861 for the motivating example of why this lint is doing that (and the doc comment in the code I added).
This invariant is really easy to miss and error prone: in the old code, every other
} else {branch needed aself.span_to_lint_map.insert(.., None)call.This PR moves out the logic that checks if an expression needs to be a vec based on its surrounding environment. This way we can cover all cases with one
elseat its callsite and only need to insertNonein one isolated place.I was also working on extending this lint with another pattern, where refactoring the "does this expression need to be a vec or does a slice work too" into its own function would be very convenient.
(Tbh, I don't think this invariant/FP actually matters much in practice, because it's a bit of an edge case IMO. I don't think it's really worth all the complexity (even though I was the one to suggest how we could fix this in the linked issue). This is also already an issue with every other lint that can change an expression's type. I also don't know if this is compatible with "incremental lints", which IIUC work per-module (I know that MSRV handling recently had to change due to that). In any case, I just decided to keep it for now so that this is purely an internal refactor without user facing changes.)
Fixes #14531 (indirectly, added a test for it)
changelog: none