Skip to content

New lint: vec_from_literal_array - #17482

Open
DanielEScherzer wants to merge 6 commits into
rust-lang:masterfrom
DanielEScherzer:vec_from_literal_array
Open

New lint: vec_from_literal_array#17482
DanielEScherzer wants to merge 6 commits into
rust-lang:masterfrom
DanielEScherzer:vec_from_literal_array

Conversation

@DanielEScherzer

@DanielEScherzer DanielEScherzer commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

View all comments

  • Followed lint naming conventions
  • Added passing UI tests (including committed .stderr file)
  • cargo test passes locally
  • Executed cargo dev update_lints
  • Added lint documentation
  • Run cargo dev fmt

Fixes #17478


changelog: [vec_from_literal_array]: add lint

@rustbot rustbot added the S-waiting-on-community-reviews Status: This is awaiting for positive reviews from the community before a maintainer is assigned. label Jul 31, 2026
@rustbot

rustbot commented Jul 31, 2026

Copy link
Copy Markdown
Collaborator

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 (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@rustbot rustbot added needs-fcp PRs that add, remove, or rename lints and need an FCP S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Jul 31, 2026

@CommanderStorm CommanderStorm left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.
Not sure about pedantic.. could also be stylstic?
This is something for the fcp though.

View changes since this review

Comment thread tests/ui/vec_from_literal_array.rs
Comment thread tests/ui/vec_from_literal_array.rs
Comment thread clippy_lints/src/vec_from_literal_array.rs Outdated
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

@y21 y21 Aug 1, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)?

View changes since the review

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread clippy_lints/src/vec_from_literal_array.rs Outdated
@DanielEScherzer
DanielEScherzer force-pushed the vec_from_literal_array branch from 206c081 to 9b01938 Compare August 1, 2026 21:30
Comment on lines +17 to +19
/// 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.

@Gri-ffin Gri-ffin Aug 5, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

View changes since the review

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@rustbot

This comment has been minimized.

@DanielEScherzer
DanielEScherzer force-pushed the vec_from_literal_array branch from fcacd0c to 1e9abae Compare August 8, 2026 13:27
@rustbot

This comment has been minimized.

@rustbot

This comment has been minimized.

@rustbot

rustbot commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

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.

@DanielEScherzer

Copy link
Copy Markdown
Contributor Author

@Gri-ffin would you mind taking another look so this can hopefully move towards FCP?

@Gri-ffin Gri-ffin left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the case of [a; n].to_vec(), I think it should be handled by this lint.

View changes since this review

@rustbot rustbot removed the S-waiting-on-community-reviews Status: This is awaiting for positive reviews from the community before a maintainer is assigned. label Aug 12, 2026
@rustbot

rustbot commented Aug 12, 2026

Copy link
Copy Markdown
Collaborator

r? @dswij

rustbot has assigned @dswij for the project review.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: 8 candidates
  • 8 candidates expanded to 8 candidates
  • Random selection from Jarcho, Manishearth, dswij, llogiq

@rustbot

rustbot commented Aug 12, 2026

Copy link
Copy Markdown
Collaborator

☔ The latest upstream changes (possibly #17552) made this pull request unmergeable. Please resolve the merge conflicts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs-fcp PRs that add, remove, or rename lints and need an FCP S-waiting-on-review Status: Awaiting review from the assignee but also interested parties

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Lint on slice literals i.e. [...].to_vec() and instead suggest vec![]

7 participants