Skip to content

Clippy subtree update #144449

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 150 commits into from
Jul 25, 2025
Merged

Clippy subtree update #144449

merged 150 commits into from
Jul 25, 2025

Conversation

flip1995
Copy link
Member

samueltardieu and others added 30 commits May 21, 2025 17:17
The first non-MSRV-compatible item located under a `#[cfg(…)]` or
`#[cfg_attr(…)]` attribute will get an additional note suggesting
changing `#[clippy::msrv]` locally.
A later commit will introduce the non-linting of feature-enabled items.
Switch to public items from `core` for the tests as to not interfere.
If an item has been enabled through a feature, it will not be linted
even though the MSRV is not compatible. This use case may happen when
stable compilers are allowed to enable unstable features, e.g. in
the Rust for Linux toolchain.
New Rust releases also stabilize enum variants, constants, and so on.
Lint them as well.
Also, update error marker for consistency.
To limit false positives, the `range_plus_one` and `range_minus_one` lints
will restrict themselves to situations where the iterator types can be easily
switched from exclusive to inclusive or vice-versa. This includes situations
where the range is used as an iterator, or is used for indexing. Also,
when the range is used as a function or method call argument and the
parameter type is generic over traits implemented by both kind of
ranges, the lint will trigger.

On the other hand, assignments of the range to variables, including
automatically typed ones or wildcards, will no longer trigger the lint.
However, the cases where such an assignment would benefit from the lint
are probably rare.

This fix doesn't prevent false positives from happening. A more complete
fix would check if the obligations can be satisfied by the new proposed
range type.
Those lints share the detection logic structure, but differed, probably
because of an oversight, in lint emission: only one of them would take
care of emitting parentheses around the suggestion if required.

Factor the code into one function which checks for the right condition
and emits the lint in an identical way.
However, if they appear within the context of a function argument, they
will be marked as certain, as they might eventually be considered `i32`
by default if the context is not more specific.

Also, in the case of binary expressions, if one of the side is
uncertain, then the certainty will come from the other side.
`Node::Param(…)` can represent function parameters as well as closure
parameters. In the second case, a type is not always given. When no
type is given, consider it uncertain.
- `&a % &b == 0` compiles, but requires dereferencing `b` when
  replacing with `a.is_multiple_of(b)`.
- In `a % b == 0`, if type of `a` is not certain,
  `a.is_multiple_of(b)` might not be typable.
- In `a % b == 0`, `a` and `b` must be unsigned integers, not any
  arbitrary types implementing `Rem` and outputing an integer.
Removes an unnecessary use of `span_lint_hir_and_then()` where
`span_lint_and_then()` would do.
This also moves the lint to be posted on the call.
This removes the need for using source snippets in the replacement.
@rustbot rustbot added the T-clippy Relevant to the Clippy team. label Jul 25, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jul 25, 2025

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

@rustbot

This comment was marked as spam.

@rust-log-analyzer

This comment has been minimized.

@rustbot rustbot added the T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) label Jul 25, 2025
@@ -19,6 +19,7 @@ const IGNORED_RULES_FOR_STD_AND_RUSTC: &[&str] = &[
"too_many_arguments",
"needless_lifetimes", // people want to keep the lifetimes
"wrong_self_convention",
"approx_constant", // libcore is what defines those
Copy link
Member Author

Choose a reason for hiding this comment

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

I hope this is the right fix 🤔

@Manishearth
Copy link
Member

@bors r+ p=1 roll up=never

@bors
Copy link
Collaborator

bors commented Jul 25, 2025

📌 Commit 9660038 has been approved by Manishearth

It is now in the queue for this repository.

@bors bors 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 Jul 25, 2025
@bors
Copy link
Collaborator

bors commented Jul 25, 2025

⌛ Testing commit 9660038 with merge f639026...

bors added a commit that referenced this pull request Jul 25, 2025
@bors
Copy link
Collaborator

bors commented Jul 25, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jul 25, 2025
@flip1995
Copy link
Member Author

Canceling since a higher priority waiting request for CI-refs/heads/auto exists

Not sure if this has to be re-queued

@Manishearth
Copy link
Member

@bors retry

@bors bors 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 Jul 25, 2025
@bors
Copy link
Collaborator

bors commented Jul 25, 2025

⌛ Testing commit 9660038 with merge 430d6ed...

@bors
Copy link
Collaborator

bors commented Jul 25, 2025

☀️ Test successful - checks-actions
Approved by: Manishearth
Pushing 430d6ed to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 25, 2025
@bors bors merged commit 430d6ed into rust-lang:master Jul 25, 2025
11 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jul 25, 2025
Copy link
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 a955f1c (parent) -> 430d6ed (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 430d6eddfc6a455ca4a0137c0822a982cccd3b2b --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. dist-apple-various: 5975.7s -> 8300.5s (38.9%)
  2. dist-aarch64-linux: 8855.6s -> 5919.8s (-33.2%)
  3. x86_64-apple-2: 4792.2s -> 5742.1s (19.8%)
  4. aarch64-apple: 5119.9s -> 6090.1s (19.0%)
  5. x86_64-msvc-1: 8319.5s -> 9205.7s (10.7%)
  6. dist-x86_64-apple: 10390.2s -> 9288.1s (-10.6%)
  7. dist-arm-linux-gnueabi: 5141.0s -> 4653.9s (-9.5%)
  8. aarch64-msvc-1: 6642.1s -> 7258.7s (9.3%)
  9. dist-riscv64-linux: 5065.5s -> 4680.4s (-7.6%)
  10. aarch64-msvc-2: 5394.2s -> 5785.0s (7.2%)
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
Collaborator

Finished benchmarking commit (430d6ed): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

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

Max RSS (memory usage)

Results (secondary 4.0%)

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)
4.0% [4.0%, 4.0%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 467.355s -> 468.925s (0.34%)
Artifact size: 374.67 MiB -> 374.68 MiB (0.00%)

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. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.