New lint: const_size_windows

[DanBondarenko]

See #6580

This adds a new lint const_size_windows (currently registered under style). This lint checks for usage of slice::windows with a constant window size that can be replaced with slice::array_windows, enabling array destructuring.

This lint verifies that:

• The windows method, specifically the implementation on the slice type, has been called.
• The size argument, passed to the method, is const-evaluatable.
• The entirety of the method call is not within a macro expansion while allowing for expansion of receiver or args.
• The Rust version is at least 1.94.0, the version when array_windows was stabilized [2].

This lint has code suggestion behaviour:

• It suggests MachineApplicable code with the source-equivalent slice::array_windows call.
• It checks whether array_windows has been implemented for another trait on the receiver, suggesting UFCS in those cases.
• It checks whether size is a complex const requiring surrounding braces as a generic const parameter in the suggestion.

This lint offers an additional note alongside the suggestion:

• It shows an example of a for loop using array destructuring on the iterator items.
• The iterator expression is the source-equivalent slice::array_windows call.
• The array destructuring accounts for the const-evaluatable size if possible: size = 2 destructures to [left, right], size = 3 to [x, y, z] etc. This liberates us from specifying the generic const parameter specification in the majority of cases.
• The array destructuring checks whether the code-example variables are already in use within the function, in which case alternative variable names are used.

Limitations of the lint:

• The lint does not destructure iterated items into arrays as part of its code suggestion. An example of potential destructuring is shown as a separate note.
• The lint does not leverage inferred size via array destructuring as part of its code suggestion. However, array destructuring and thereby inferred const generics are demonstrated in the example shown in the additional note.
• The lint does not detect usages of slice::chunks with const size. The chunks method does not have a clean equivalent transformation since as_chunks has a different return type [3].

Open question: Should this be a perf lint or a style lint?

• The original issue New lint: windows_const and chunks_const #6580 suggests this as a perf lint.
• I did not find any benchmarks comparing slice::array_windows to slice::windows.
• The release notes for slice::array_windows mention optimization [1]:

  • If we had used the older .windows(4) iterator, then that argument would be a slice which we would have to index manually, hoping that runtime bounds-checking will be optimized away.

changelog: new lint: [const_size_windows]

---

• Followed [lint naming conventions][lint_naming]: "Deny const-size windows" / "Allow const-size windows"
• Added passing UI tests (including committed .stderr file): 29 positive test cases, 19 negative test cases
• cargo test passes locally
• Executed cargo dev update_lints
• Added lint documentation
• Run cargo dev fmt

[github-actions]

No changes for ba79030

[Gri-ffin]

Why do we need to check all traits, even private ones here?

View changes since the review

[DanBondarenko]

@Gri-ffin Well spotted! Checking for private traits here was overkill – I changed this to TyCtxt::visible_traits in the a newer commit.

I'll also shortly describe the reason for checking traits in general:

• This lint has the ambition of providing a MachineApplicable suggestion when possible.
• Potential source of invalid suggestions is the receiver implementing another trait with a array_windows method; in which case a naive windows -> array_windows replacement may cause the method to resolve to the trait implementation instead of the slice::array_windows method.
• To this end, I added checks to detect such ambiguities; when detected, UFCS is used in the replacement snippet: <[_]>::array_windows::<N>(&recv) instead of recv.array_windows::<N>().

[rustbot]

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.