Skip to content

Clippy subtree update - #161416

Merged
rust-bors[bot] merged 124 commits into
rust-lang:mainfrom
flip1995:clippy-subtree-update
Aug 24, 2026
Merged

Clippy subtree update#161416
rust-bors[bot] merged 124 commits into
rust-lang:mainfrom
flip1995:clippy-subtree-update

Conversation

@flip1995

@flip1995 flip1995 commented Aug 20, 2026

Copy link
Copy Markdown
Member

View all comments

r? Manishearth

Cargo.lock update due to Clippy version bump

Gri-ffin and others added 30 commits July 10, 2026 20:08
Folding over an Option's iterator visits zero or one items, which is
map_or in disguise: opt.iter().fold(init, |acc, x| f(acc, x)) is
opt.as_ref().map_or(init, |x| f(init, x)) (as_mut for iter_mut, plain
map_or for into_iter, which consumes the Option).

This extends unnecessary_fold rather than adding a new lint, and only
runs when none of the existing any/all/sum/product cases fired, so
existing behavior is unchanged. Accumulator uses in the closure body
are substituted with the init expression; the suggestion is
machine-applicable when the accumulator is unused or init is a literal
or a Copy binding, downgraded to MaybeIncorrect when substituting
duplicates a re-evaluated expression, and omitted entirely when it
would move a non-Copy binding twice.
…turn

Restrict the Option-fold case to init expressions that can be duplicated
into the closure without changing behavior: literals and bindings of
Copy types. Arbitrary expressions (re-evaluated only in the Some case)
and non-Copy bindings (moved twice) are no longer linted at all, so
every emitted suggestion is machine-applicable and the MaybeIncorrect
and suggestion-less paths are gone. Also replace the fired flag with an
early return from the extracted check_standard_fold.
Replace the string splicing with a multipart suggestion that rewrites
the fold call, drops the accumulator parameter, and substitutes init
for each accumulator use. Also reject closure parameters as init: with
nested folds the enclosing closure may itself be rewritten by this
lint, which would leave the substituted name unresolved. Covers both
nesting directions with tests.
This has multiple advantages:

 - Performance. The new type is 1/3 the size of `Vec` (being equivalent in layout to `Option<ThinVec>`) and can be kept in a register.
 - Type safety. We mark the type `#[must_use]`, and thinks requiring errors take `ThinVec`, which requires unwrapping the type and verifying there is indeed an error. We still provide conversions to slices, `ThinVec`, and iteration, because some code needs this and I saw no benefit in changing it, but we deliberately do not provide `Deref<Target = [E]>` or things like that.
…g#16634)

Closes rust-lang/rust-clippy#11529
Closes rust-lang/rust-clippy#16631
Closes rust-lang/rust-clippy#15560
Closes rust-lang/rust-clippy#16344

This PR addresses two problems of `needless_range_loop`:
1. It suggests wrongly when the index is after other indexes or field
accesses.
2. When the index is nested, it does not specify which index to replace,
making the suggestion confusing.

changelog: [`needless_range_loop`] fix wrong suggestions for nested
index
*[View all
comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust-clippy/pull/17499)*

Adds `unnecessary_nonzero_get`, a `complexity` lint that drops
`NonZero::get()` when the following method or operator is available on
`NonZero` itself with the same return type.

```rust
let _ = nz.get().leading_zeros();  // -> nz.leading_zeros()
let _ = x / nz.get();              // -> x / nz
```

Methods only match when the `NonZero` version returns the same type.
Cases like `bit_width` and `count_ones` return `NonZero`, so rewriting
those would move the `get` instead of removing it, and they are skipped.

Operators cover `/`, `%`, `/=` and `%=`. Three constraints keep the
suggestion sound:

- unsigned only, since `core` generates `Div`/`Rem` for `NonZero` from
the unsigned arm only
- not in const contexts, since the impls are `#[rustc_const_unstable]`
- exact operand types, since primitive operators forward references but
the `NonZero` impls do not

MSRV is read from the impl or method rather than hardcoded.

fixes rust-lang/rust-clippy#17483

- [x] Followed [lint naming conventions][lint_naming]
- [x] Added passing UI tests (including committed `.stderr` file)
- [x] `cargo test` passes locally
- [x] Executed `cargo dev update_lints`
- [x] Added lint documentation
- [x] Run `cargo dev fmt`

[lint_naming]:
https://rust-lang.github.io/rfcs/0344-conventions-galore.html#lints

changelog: new lint: [`unnecessary_nonzero_get`]
When checking stdout/err, color codes will get in the way of the simple comparisons that are performed during tests.
Anyone setting CARGO_TERM_COLOR=always will experience test failures as a result.
This forcibly disables coloring.
…ust-lang#17530)

fixes rust-lang/rust-clippy#17501

changelog: [`cast_possible_truncation`]: fix `try_from` suggestion
expanding macros instead of showing the macro call
When checking stdout/err, color codes will get in the way of the simple
comparisons that are performed during tests. Anyone setting
CARGO_TERM_COLOR=always will experience test failures as a result. This
forcibly disables coloring for those tests that rely on doing a direct
comparison.

changelog: none
Extend the lint to catch

    if c {
        return W(true);
    }
    W(false)

and reduce it to `W(c)` (or `W(!c)`), where `W` is an optional tuple-like
constructor (`Ok`/`Some`/user enum & tuple-struct ctors) shared by both the
guard and the trailing expression, or absent.

Constructors are pure, so folding the condition into them preserves behavior.
The values must differ (equal values are skipped, since the condition could
have side effects), the guard body must be only the `return`, and the same
constructor must wrap both bools.

Also applies the new check to clippy's own source (dogfood).
Manishearth and others added 8 commits August 23, 2026 06:57
With the new trait solver enabled by default in nightly-2026-08-22 [1],
large_futures can ICE while inspecting an awaited future.

The lint switches to Codegen mode to obtain coroutine layouts but passes
a type whose opaque aliases are still marked rigid from type checking.
Because layout_of receives an already-Codegen environment, its
environment-change path does not clear those markers.

Clear alias rigidity and normalize the awaited type in that environment
before querying its layout. Codegen mode must remain: post-analysis
layout queries cannot compute coroutine sizes [2].

The regression covers direct and pinned futures under both solvers,
without other lint errors that could hide a delayed ICE.

Fixes rust-lang#161495.

changelog: [`large_futures`]: Fix an ICE on awaited futures with the
next trait solver.

[1]: rust-lang#160619
[2]: rust-lang#145477
r? @ghost

Another sync, as I want to resolve the conflicts on this side to do a
clean Josh sync soon ™️

changelog: none
Simplify bool condition in llvm CI download availability check in bootstrap
@flip1995
flip1995 force-pushed the clippy-subtree-update branch from 49944d9 to be9e487 Compare August 23, 2026 17:46
@flip1995
flip1995 marked this pull request as ready for review August 23, 2026 18:01
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 23, 2026
@rustbot

rustbot commented Aug 23, 2026

Copy link
Copy Markdown
Collaborator

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

HIR ty lowering was modified

cc @fmease

@rustbot rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 23, 2026
@rustbot

rustbot commented Aug 23, 2026

Copy link
Copy Markdown
Collaborator

⚠️ Warning ⚠️

@flip1995

Copy link
Copy Markdown
Member Author

Should be ready now. tests and x clippy ci passed for me locally.

@samueltardieu

Copy link
Copy Markdown
Member

@bors r+ rollup=never p=1 subtree update

@rust-bors

rust-bors Bot commented Aug 23, 2026

Copy link
Copy Markdown
Contributor

📌 Commit be9e487 has been approved by samueltardieu

It is now in the queue for this repository.

@rust-bors rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 23, 2026
}

false
!ocx.try_evaluate_obligations().no_errors()

@flip1995 flip1995 Aug 23, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

This is basically .has_errors(), but I wasn't sure whether the !.no_errors() was intentional, in case the Errors enum is extended in the future 🤷 Or if HasErrors(vec![]) with an empty vec should also not be considered.

View changes since the review

Comment on lines +375 to +378
// Check if the host target is available with the requested assertions (true/false),
supported_platforms.contains(&(&*host_target.triple, asserts))
// if it is not available for the given `asserts`, check if it is available with assertions (superset).
|| supported_platforms.contains(&(&*host_target.triple, true))

@flip1995 flip1995 Aug 23, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

This should be equivalent, but also way easier to understand. Please double check.

View changes since the review

@rust-bors

This comment has been minimized.

@rust-bors rust-bors Bot added merged-by-bors This PR was explicitly merged by bors. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 24, 2026
@rust-bors

rust-bors Bot commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

☀️ Test successful - CI
Approved by: samueltardieu
Duration: 3h 5m 54s
Pushing da51146 to main...

@rust-bors
rust-bors Bot merged commit da51146 into rust-lang:main Aug 24, 2026
14 checks passed
@rustbot rustbot added this to the 1.100.0 milestone Aug 24, 2026
@rust-bors rust-bors Bot mentioned this pull request Aug 24, 2026
@github-actions

Copy link
Copy Markdown
Contributor
What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing fb6531d (parent) -> da51146 (this PR)

Test differences

Show 4 test diffs

4 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard da5114692c9ebe46b869488c5f34f92eb10b98c1 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. i686-gnu-nopt-2: -> 1h 33m (+inf%)
  2. test-various: -> 2h 9m (+inf%)
  3. dist-arm-linux-gnueabi: -> 1h 31m (+inf%)
  4. dist-ohos-armv7: -> 1h 15m (+inf%)
  5. dist-i686-linux: -> 1h 50m (+inf%)
  6. dist-various-2: -> 47m 50s (+inf%)
  7. x86_64-gnu-debug: -> 2h 5m (+inf%)
  8. dist-aarch64-apple: -> 1h 55m (+inf%)
  9. x86_64-mingw-1: -> 2h 51m (+inf%)
  10. dist-i686-msvc: -> 2h 6m (+inf%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer

Copy link
Copy Markdown
Collaborator

Finished benchmarking commit (da51146): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

Results (secondary -6.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-6.7% [-6.7%, -6.7%] 1
All ❌✅ (primary) - - 0

Cycles

Results (primary 2.4%, secondary 4.2%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
2.4% [2.4%, 2.4%] 1
Regressions ❌
(secondary)
4.2% [4.2%, 4.2%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.4% [2.4%, 2.4%] 1

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 469.882s -> 469.244s (-0.14%)
Artifact size: 400.35 MiB -> 400.19 MiB (-0.04%)

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

Labels

merged-by-bors This PR was explicitly merged by bors. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-clippy Relevant to the Clippy team.

Projects

None yet

Development

Successfully merging this pull request may close these issues.