Clippy subtree update - #161416
Conversation
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.
Per [#t-infra > funding link on rust-lang/rust is broken @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/funding.20link.20on.20rust-lang.2Frust.20is.20broken/near/615432496), the current link is broken. changelog: none
…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
Closes rust-lang/rust-clippy#16798 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).
Fixes problem [reported in Zulip](https://rust-lang.zulipchat.com/#narrow/channel/257328-t-clippy/topic/The.20clippy.20channel.20link.20for.20zulip.20doesn.27t.20seem.20to.20work/with/618159412). r? @Manishearth changelog: none
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
49944d9 to
be9e487
Compare
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt HIR ty lowering was modified cc @fmease |
|
|
Should be ready now. tests and |
|
@bors r+ rollup=never p=1 subtree update |
| } | ||
|
|
||
| false | ||
| !ocx.try_evaluate_obligations().no_errors() |
There was a problem hiding this comment.
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.
| // 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)) |
There was a problem hiding this comment.
This should be equivalent, but also way easier to understand. Please double check.
This comment has been minimized.
This comment has been minimized.
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 differencesShow 4 test diffs4 doctest diffs were found. These are ignored, as they are noisy. Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard da5114692c9ebe46b869488c5f34f92eb10b98c1 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (da51146): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis 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.
CyclesResults (primary 2.4%, secondary 4.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 469.882s -> 469.244s (-0.14%) |
View all comments
r? Manishearth
Cargo.lock update due to Clippy version bump