Clippy subtree update#159789
Open
flip1995 wants to merge 113 commits into
Open
Conversation
Because of the way this lint implements text splitting, I need to track markdown and text lengths separately. This is fairly easy, since we can exhaustively check every markdown event and count the characters inside.
test: supply test for issue 16954. fix: suggest MethodCall for expr with type anchor. fix: remove redudant is_lit check. fix: missing parenthesis for a * b. fix: remove redundant lit check.
This better matches how the argument is actually used.
See `rustc_hir::intravisit::{walk_expr,walk_pat_expr}`.
…modes Implement configuration-based approach with three options: - alphabetical (default) - trait_item_ordering - alphabetical_or_trait_item_ordering Fixes false positives for non-alphabetically-ordered trait definitions.
…ait_item_ordering` and `alphabetical_or_trait_item_ordering
The `opt.and_then(|x| { /* comment */ if .. { Some(x) } else { None } })`
to `filter` rewrite drops any comment inside the closure. Mark the
suggestion `MaybeIncorrect` when the replaced span contains a comment, so
`clippy --fix` no longer applies it silently. This matches the existing
`span_contains_comment` handling in manual_ok_err / manual_unwrap_or /
manual_flatten.
…ingjubilee Carry the `b_offset` inside `BackendRepr::ScalarPair` Inspired by rust-lang/compiler-team#1007 but doesn't actually change any of the layout rules just yet. This turned out to be a nice change even if we didn't use the extra flexibility, IMHO, because it allowed so many things like ```diff @@ -222,12 +224,12 @@ fn from_const_alloc<Bx: BuilderMethods<'a, 'tcx, Value = V>>( let val = read_scalar(offset, size, s, bx.immediate_backend_type(layout)); OperandRef { val: OperandValue::Immediate(val), layout, move_annotation: None } } - BackendRepr::ScalarPair( - a @ abi::Scalar::Initialized { .. }, - b @ abi::Scalar::Initialized { .. }, - ) => { + BackendRepr::ScalarPair { + a: a @ abi::Scalar::Initialized { .. }, + b: b @ abi::Scalar::Initialized { .. }, + b_offset, + } => { let (a_size, b_size) = (a.size(bx), b.size(bx)); - let b_offset = (offset + a_size).align_to(b.default_align(bx).abi); assert!(b_offset.bytes() > 0); let a_val = read_scalar( offset, ``` as *oh my* was that little magic incantation copy-pasted all over the place. Apologies for the pretty-giant PR. I tried to make it as direct a change as I could: if it was `(..)` before it's `{ .. }` now, if it was `(_, _)` before it's `{ a: _, b: _, b_offset: _ }` now. I kept the names the same so the code lines were unchanged even if normally I might have just renamed things, etc. I'll add some inline notes for places of particular interest. r? @workingjubilee
…is empty. This matches the same check from disallowed_macros and skips unnecessary work when the rule has been enabled but not configured.
This PR enables [the community reviews feature](https://forge.rust-lang.org/triagebot/pr-assignment.html#community-reviews) in triagebot. It's configured to require **2 approvals** before automatic assignment kicks in; manual assignments (`r?`) bypass this requirement. It's signaled (and controlled) on a PR with the `S-waiting-on-community-reviews` label ~~(to be created)~~. Context: - [#general > Article: Open Code Review at Bevy](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/Article.3A.20Open.20Code.20Review.20at.20Bevy/with/604251242) - [#clippy > External approvals and review](https://rust-lang.zulipchat.com/#narrow/channel/257328-clippy/topic/External.20approvals.20and.20review/with/604254405) - [Together for a healthier Clippy](https://blog.rust-lang.org/inside-rust/2026/07/06/unite-for-clippy/) cc @samueltardieu @blyxyas changelog: "none"
changelog: none r? ghost
…name, r=lolbinarycat rustdoc: do not include extra stuff in span This change prevents our lints from returning a span with stuff in it that isn't actually part of the doc comment. When that happens, it returns `None` instead. Fixes rust-lang/rust-clippy#16169, since the bug was reported against the `clippy::doc_paragraphs_missing_punctuation` lint but is actually a bug in `source_span_for_markdown_range_inner`.
allow mGCA const arguments to fall back to anon consts makes good progress on rust-lang/project-const-generics#108 `min_generic_const_args` (mGCA) is all about "is this const lowered to a const item with a body, or, is it "directly" represented and visible in the type system?" Here's various answers to the question of "can we represent this const arg directly?" - if we answer "no", then we fall back to an anon const (or error, sometimes, depending on context) on **stable**, the full list of things can be directly represented is (... it's just the one thing) - paths to generic const parameters on `main`, under mGCA, **before** this PR: - absolutely everything, if something cannot be represented directly, compiler error - `const { }` gives you an escape hatch to go back to being an anon const on macro**ful** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro on macro**less** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro (not *particularly* useful under macro**less** gca) - struct expressions, arrays, blah blah - currently, paths to *anything*, even if that produces a compiler error later down the line (potential followup work here...) this PR implements macro**less** gca, with the intent of a quick follow-up introducing a "macroless gca" feature and transitioning `#[feature(min_generic_const_args)]` to be macro**ful** gca Also of note is that this PR removes the logic to skip generating "fake" DefIds for directly represented AnonConsts under mGCA, we now always generate a DefId when encountering an AnonConst. This lines up with stable, which has a fake AnonConst DefId for a directly represented plain path generic parameter (i.e. the bullet point under the "stable" entry above). r? @BoxyUwU
…, r=oli-obk view-types: HIR lowering
Specifically, from `Block`, `Pat`, `Path`, `Ty`, `Visibility`. This field is usually `None`. It only gets filled in for paths that might later be re-tokenized via `TokenStream::from_ast`, e.g. because of macro or cfg use. All such cases go through a single place: `parse_nonterminal`. This commit changes `parse_nonterminal` to store the non-`None` lazy attr token stream *next* to the node in `ParseNtResult` (using the new `WithTokens` type) instead of *inside* the parsed node. Along with some minor changes to the relevant `HasTokens` and `HasAttrs` impls, this is enough for things to work. These AST nodes all shrink by 8 bytes, as do various other nodes that contain nodes of these types. A guide to the changes: - `compiler/rustc_ast/src/tokenstream.rs` has the new `WithTokens` type. - `compiler/rustc_parse/src/parser/nonterminal.rs`, `compiler/rustc_expand/src/mbe/transcribe.rs` and `compiler/rustc_parse/src/parser/mod.rs` have minor changes due to the changes to `ParseNtResult`. - `compiler/rustc_ast/src/ast_traits.rs` has the `HasTokens`/`HasAttrs` changes. - Everything else is just mechanical changes for the removal of the `tokens` field.
--- changelog: none
…t is empty. (rust-lang#17381) This matches the same check from [`disallowed_macros`](https://github.com/rust-lang/rust-clippy/blob/d22d01ee1332567e7bafd610f1aa9115e10fc0cb/clippy_lints/src/disallowed_macros.rs#L99) and skips unnecessary work when the rule has been enabled but not configured. changelog: none
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust-clippy/pull/16855)* This PR introduces a new late pass lint to catch scrutinees unnecessarily wrapped in blocks on older editions, preventing unintended behavior regarding temporary lifetimes. Fixes rust-lang/rust-clippy#16827 changelog: new lint: [`block_scrutinee`] to warn on scrutinees wrapped in blocks in older editions
rust-lang#17369) This PR requires `as _` in Clippy sources when importing a trait name which is not directly used, as to not pollute the namespace (first commit). It also activate the `clippy::unused_trait_names` in dogfood (second commit). changelog: none
…rust-lang#16800) Closes rust-lang/rust-clippy#16792 For unsigned types, `if x == 0` can be expressed as `if x < 1`. The former was not caught by `manual_clamp` lint; this PR normalizes it so that cases as described in the linked issue are caught. changelog: `manual_clamp` detect `== 0` on unsigned types as a clamp lower bound
This is inspired by the compiler. Ideally, this function should be provided by the compiler itself.
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust-clippy/pull/16633)* changelog: [`double_must_use`, `let_underscore_must_use`, `must_use_candidates`]: better determination of `#[must_use]` needs by directly using the compiler algorithm For example, `Box<T>` is considered `#[must_use]` when `T` is.
Update the link target to avoid a redirect from the rust-lang-nursery address, and wrap the URL in angle brackets so that it gets rendered as a link.
* Directly access the identifiers instead of using a visitor. * Don't lint functions with linking related attributes (e.g. `no_mangle`). * Delay checking for external macros. * Check the length in code-points and not bytes. * Only walk up the HIR tree if we need to check for trait impl function parameters. * State the number of missing characters in the lint message.
Changes: * Directly access the identifiers instead of using a visitor. * Don't lint functions with linking related attributes (e.g. `no_mangle`). * Delay checking for external macros. * Check the length in code-points and not bytes. * Only walk up the HIR tree if we need to check for trait impl function parameters. * State the number of missing characters in the lint message. changelog: none
changelog: [`cargo_common_metadata`]: update link in documentation
changelog: none r? ada4a
fixes rust-lang/rust-clippy#17373 Don't try to reason about macro expanded conditions. Also pass the condition's `ctxt` instead of the expression's. changelog: [`if_not_else`]: do not lint on macro expanded conditions.
## Summary Fix 4 WAVE accessibility errors on the Clippy lints page (rust-lang/rust-clippy#15604). The `theme-choice` <select> and three version-filter <input> elements had no programmatically associated labels, making them unidentifiable to screen readers. ## Changes - `util/gh-pages/index_template.html:34` — changed `<div class="setting-radio-name">` to `<label class="setting-radio-name" for="theme-choice">` to associate the visible "Theme" text with the select element - `util/gh-pages/index_template.html:121-123` — added `for="version-filter-{{ name }}"` on each version label and `id="version-filter-{{ name }}"` on each version input, producing three pairings: version-filter-gte, version-filter-lte, version-filter-eq - `tests/lint-page.rs` (new) — regression test asserting all four label associations exist in the template ## Not in scope Colors, contrast, CSS, JavaScript, and lint logic are untouched. ## Convention Uses `<label for="">`, the same pattern already established in the template for the search input (line 155). ## Test cargo test --test lint-page — 1 passed, 0 failed. changelog: Fix accessible labels for the theme and version filters on the lint page Part of rust-lang/rust-clippy#15604
r? @ghost changelog: none
Collaborator
|
cc @rust-lang/clippy |
rustbot
added
S-waiting-on-review
Collaborator
|
Contributor
|
☔ The latest upstream changes (presumably #159814) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. |
Member
|
r=me but i'm on vacation and will be slow |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
r? Manishearth