Clippy subtree update - #159789
Conversation
This fix adds an aditional check, by checking if the previous element was an image, and ignoring the lack of punctuation for a subsequent link. An aditional test was added to account for this case. Closes rust-lang#16439
The main value of this help text is only provided when the developer already provided all the fields. So a better example is showing the developer that this lint can be used to clean up those struct initalizations. Besides the lint already points to the ...zero_point line so the developer is inclined to remove it.
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}`.
Detect `match` expressions where every arm is a block ending in the same trailing expression and the `match` is in tail position, suggesting the expression be hoisted out below the `match`. changelog: [`branches_sharing_code`]: also lint `match` expressions whose arms end with the same expression
…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"
|
Cannot parse build command: Missing SHA in build command |
|
@rust-timer build 8092651 profiles=clippy |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Clippy subtree update r? Manishearth
|
Finished benchmarking commit (8092651): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. Next, please: If you can, justify the regressions found in this try perf run in writing along with @bors rollup=never rustc-perf Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary 1.1%, secondary 1.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary -1.4%, secondary -0.7%)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: 491.018s -> 490.184s (-0.17%) |
|
The job Click to see the possible cause of the failure (guessed by this bot)Important For more information how to resolve CI failures of this job, visit this link. |
|
💔 Test for d8206ac failed: CI. Failed job:
|
|
@bors retry |
|
@bors treeclosed=1000 |
|
Tree closed for PRs with priority less than 1000. |
|
@bors p=4 |
|
☔ The latest upstream changes (presumably #160517) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. This pull request was unapproved. |
|
Would simply rebasing this PR work or would that break the subtree sync process? I don't fully understand the process, just throwing out the suggestion |
|
Tomorrow is the regular sync day anyway 😅 So I close this PR and redo it tomorrow, so we're back to the normal cycle. |
No, rebasing would break the subtree sync process. The SHAs would not match the SHAs in the Clippy repo. Let's hope this is the last sync ever done with |
View all comments
r? Manishearth