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_map
map 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
else
at its callsite and only need to insertNone
in 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.)
changelog: none