fix: do not machine-apply chunks_exact_to_as_chunks rewrites by cestercian · Pull Request #17642 · rust-lang/rust-clippy

cestercian · 2026-08-27T20:21:14Z

I did not use an LLM to create a change in this PR.
I used an LLM to create a change in this PR, and I have explained below how it was used.

Cursor wrote this patch and the follow-up commits. I reviewed the diff, including the MaybeIncorrect choice (is_ty_unified does not see Item pinning), the test split into mod issue17515, and the UI tests.

chunks_exact / chunks_exact_mut yield &[T], but the suggested as_chunks::<N>() / as_chunks_mut::<N>() rewrite yields &[T; N]. Both span_suggestion arms used Applicability::MachineApplicable, so cargo clippy --fix rewrote call sites whose downstream uses pin Item to &[T] and left the crate unable to compile.

Fully proving that a use site can accept &[T; N] is not realistic (get_expr_use_site / is_ty_unified already skip some if/else cases, but not collect, map, typed closures, or return types). The suggestions are therefore MaybeIncorrect so they still appear, but are not auto-applied.

Changes

Downgrade both span_suggestion arms in chunks_exact_to_as_chunks to Applicability::MaybeIncorrect, unless the snippet already forced HasPlaceholders
Keep the lint and the rewrite text; do not add a default .map(AsRef::as_ref) wrapper
Merge the former rustfix UI test into the non-fixable test (//@no-rustfix) and add the issue 17515 repros (collect::<Vec<&[u8]>>(), map(from_utf8), typed for_each, for-loop into Vec<&[u8]>)

Related Issue

Fixes #17515

Testing

TESTNAME="chunks_exact_to_as_chunks" cargo uibless
TESTNAME="chunks_exact_to_as_chunks" cargo uitest

changelog: [chunks_exact_to_as_chunks]: do not machine-apply suggestions, since the rewrite changes Item from &[T] to &[T; N]

The suggestion rewrites `slice.chunks_exact(N)` to `as_chunks::<N>()`, which yields `&[T; N]` instead of `&[T]`. Machine-applying that via `cargo clippy --fix` breaks builds when the item type is pinned, e.g. `collect::<Vec<&[T]>>()`, `map(from_utf8)`, or typed closures. Downgrade both span_suggestion arms to MaybeIncorrect (keeping HasPlaceholders when the snippet already required it). Co-authored-by: Cestercian <yashafaid@gmail.com>

rustbot · 2026-08-27T20:21:19Z

Thanks for the pull request, and welcome!

You should hear from one of our reviewers after this PR gets at least 2 reviews from the community.

Please see the contribution instructions for more information.

Clippy's lint-attributes-organization test requires allow-list lint names in alphabetical order. Co-authored-by: Cestercian <yashafaid@gmail.com>

CommanderStorm

Community review:
I wonder if there is a more precice adjustment that we can make using our typechecking machineary. have you checked this?

I am fine with the change if there is no better solution to be had 👍🏻

View changes since this review

CommanderStorm · 2026-08-28T07:20:10Z

+//@no-rustfix: rewriting `chunks_exact` to `as_chunks` changes `Item` from `&[T]` to `&[T; N]`
 #![warn(clippy::chunks_exact_to_as_chunks)]
-#![allow(unused, clippy::redundant_closure_call)]
+#![allow(unused, clippy::deref_addrof, clippy::redundant_closure_call)]


please use expect(..) here and since it looks like deref_addrof is just one or maybe two items expect that on the item level instead.

The added expect gives us more signal for free if something breaks 😉

Done in 8302184: crate-level #![allow] is only unused now. redundant_closure_call is #[expect] on that site. Dropped deref_addrof from the allow list (wasn't needed on this file).

Nopey also change the crate level allow to an expect. Let's leave the campsite cleaner than we found it

CommanderStorm · 2026-08-28T07:21:33Z

        let _ = slice.chunks_exact(size_of::<T>());
    }
+
+    // Suggestion text for for-loop / iterator-method use sites (not rustfix-applied: Item type


please move the new tests to an mod issueXYZ to have these properly orderd.
Ideally, with one function inside per higher level invariant to not have a long long list that is hard to scan 😉

Done: issue 17515 repros are in mod issue17515 with one function per invariant (collect_vec_slice, map_from_utf8, typed_for_each, for_loop_into_vec).

CommanderStorm · 2026-08-28T07:22:53Z

+        // `as_chunks` yields `&[T; N]`, not `&[T]`. Downstream uses that pin the item
+        // type (e.g. `collect::<Vec<&[T]>>()`, `map(from_utf8)`) would fail after `--fix`.
+        if applicability != Applicability::HasPlaceholders {
+            applicability = Applicability::MaybeIncorrect;
+        }


there is no way to typecheck our way to just MaybeIncorrect in the actual case? 🤔

Looked at this — keeping blanket MaybeIncorrect (option B).

is_ty_unified only sees when the iterator type must unify (e.g. if/else arms), not Item pinning. A local check at the immediate use_expr could catch some collect / map / typed-closure pins, but:

a for binding is always ChunksExact::Item (&[T]) today, so that does not tell us whether later uses accept &[T; N]

the pin can sit arbitrarily far downstream

Restoring MachineApplicable for “simple” for _ in / .take(2) would still let --fix break the issue 17515 for-loop repro. Proving acceptance at arbitrary downstream sites isn’t realistic with the current helpers, so the suggestions stay visible but not auto-applied.

Not really an answer. Why is extending the infra not a better call?

Keep blanket MaybeIncorrect (option B). `is_ty_unified` only sees iterator-type unification, not Item pinning. A local check at the immediate use_expr could spot some collect/map/typed-closure pins, but the for-loop binding is always ChunksExact::Item (`&[T]`) and the pin can be arbitrarily far downstream, so restoring MachineApplicable for `for _ in` / `.take(2)` would still let `--fix` break the issue 17515 for-loop repro. Crate-level allow is only `unused`; `redundant_closure_call` is expected on that site. Issue 17515 repros live in `mod issue17515` with one function per invariant. Co-authored-by: Cestercian <yashafaid@gmail.com>

CommanderStorm · 2026-08-28T07:35:40Z

Also please review https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/ given that 8302184 and the previous commit was done using cursor

cestercian · 2026-08-28T08:13:20Z

Also please review https://blog.rust-lang.org/inside-rust/2026/08/05/rust-langrust-is-adopting-an-llm-policy/ given that 8302184 and the previous commit was done using cursor

thanks for the heads up 👀

I disclosed the use of AI in the PR description itself if there's anything else I need todo please let me know

blyxyas · 2026-08-28T09:11:46Z

I used an LLM to create a change in this PR, and I have explained below how it was used.

You... did not explain how it was used- Could you give us some details? (ㅇㅅㅇ❀)

rustbot added S-waiting-on-community-reviews Status: This is awaiting for positive reviews from the community before a maintainer is assigned. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Aug 27, 2026

test: order chunks_exact_to_as_chunks allow lints alphabetically

fda03ae

Clippy's lint-attributes-organization test requires allow-list lint names in alphabetical order. Co-authored-by: Cestercian <yashafaid@gmail.com>

CommanderStorm suggested changes Aug 28, 2026

View reviewed changes

cestercian requested a review from CommanderStorm August 28, 2026 08:13

Uh oh!

Uh oh!

Conversation

cestercian commented Aug 27, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Related Issue

Testing

Uh oh!

rustbot commented Aug 27, 2026

Uh oh!

CommanderStorm left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

CommanderStorm commented Aug 28, 2026

Uh oh!

cestercian commented Aug 28, 2026

Uh oh!

blyxyas commented Aug 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

cestercian commented Aug 27, 2026 •

edited by rustbot

Loading

CommanderStorm left a comment •

edited by rustbot

Loading