New lint: vec_from_literal_array - #17482
Conversation
|
Thanks for the pull request. A reviewer will take a look after it receives 2 community reviews. In the meantime, we would highly appreciate if you could try to review any of PRs waiting on community reviews. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
| fn check_expr<'tcx>(&mut self, cx: &LateContext<'tcx>, expr: &Expr<'tcx>) { | ||
| if let ExprKind::MethodCall(method_name, receiver, args, _) = expr.kind | ||
| && method_name.ident.name == sym::to_vec | ||
| && let ExprKind::Array(_) = receiver.kind |
There was a problem hiding this comment.
Is it intentional for now that this does not lint array repeat expressions, i.e. [1; 10].to_vec(), which can also be vec![1; 10] (they are a separate ExprKind::Repeat)?
There was a problem hiding this comment.
I figured that the lint name might not make sense for repetition - we could add a repetition lint separately sharing almost all of the logic, vec_from_array_repetition, but I figured I should start with normal arrays
There was a problem hiding this comment.
I'd group that under array literal personally still.
If we go by the grammar these are strictly speaking both called ArrayExpressions not literals https://doc.rust-lang.org/reference/grammar.html#railroad-summary-ArrayExpression but [1; 10] feels like a literal to me.
206c081 to
9b01938
Compare
| /// It is clearer and may be more performant to use the `vec!` macro. | ||
| /// Calling `.to_vec()` also requires that the array values be clonable; | ||
| /// `vec!` has no such requirement. |
There was a problem hiding this comment.
Calling
.to_vec()also requires that the array values be clonable;
vec!has no such requirement.
Worth noting this might change behavior for types with custom Clone implementation.
There was a problem hiding this comment.
Do you have an example of where this would matter in practice? Clone implementations with "side effects" in a way that would affect this feel very... cursed and I'm having a hard time coming up with a practical example (in which case I feel like it'd make the description longer for little gain). We have a bunch of similar perf lints that help eliminate clones and they don't explicitly point it out, either (e.g. redundant_iter_cloned).
There was a problem hiding this comment.
Hmm, well I believe in practice this wouldn't matter indeed, the "strongest" example I had in mind was related to atomic operations, It's mostly just me being a perfectionist since you never know with these edge cases.
This comment has been minimized.
This comment has been minimized.
fcacd0c to
1e9abae
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
1e9abae to
6bbc7d3
Compare
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
@Gri-ffin would you mind taking another look so this can hopefully move towards FCP? |
|
r? @dswij rustbot has assigned @dswij for the project review. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
☔ The latest upstream changes (possibly #17552) made this pull request unmergeable. Please resolve the merge conflicts. |
View all comments
.stderrfile)cargo testpasses locallycargo dev update_lintscargo dev fmtFixes #17478
changelog: [
vec_from_literal_array]: add lint