Skip to content

Clippy subtree update #139983

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 338 commits into from
Apr 23, 2025
Merged

Clippy subtree update #139983

merged 338 commits into from
Apr 23, 2025

Conversation

flip1995
Copy link
Member

r? @Manishearth

Cargo.lock update due to the Clippy version bump and because Clippy moved from rinja (unmaintained) to askama.

Last sync was skipped due to the askama issue and me not getting to fixing this in time.

samueltardieu and others added 30 commits March 25, 2025 11:19
… deprecated configurations (rust-lang#14280)

This PR does two things:
- It renames `inconsistent_struct_constructor`'s configuration from
`lint-inconsistent-struct-field-initializers` to
`check-inconsistent-struct-field-initializers`. (I should have suggested
`check-...` in
[rust-lang#13737](rust-lang/rust-clippy#13737 (comment)).)
- It causes Clippy to no longer suggest deprecated configurations.
(Previously, Clippy would suggest `cyclomatic-complexity-threshold`, for
example.)

r? @y21

changelog: Rename `lint-inconsistent-struct-field-initializers` to
`check-inconsistent-struct-field-initializers`
changelog: No longer suggest deprecated configurations
This lint was downgraded to `pedantic` in part because rust-analyzer was not fully supporting it at the time per rust-lang#10087. The support has been added over [a year ago](rust-lang/rust-analyzer#11260), so seems like this should be back to style.

Another source of the initial frustration was fixed since then as well - this lint does not trigger by default in case only some arguments can be inlined.
This lint was downgraded to `pedantic` in part because rust-analyzer was not fully supporting it at the time per rust-lang#10087. The support has been added over [a year ago](rust-lang/rust-analyzer#11260), so seems like this should be back to style.

Another source of the initial frustration was fixed since then as well - this lint does not trigger by default in case only some arguments can be inlined.
…ension_comparions` (rust-lang#14358)

close rust-lang#14357

changelog: [`case_sensitive_file_extension_comparisons`]: suggest
`is_some_and` to suppress other lint warnings
"paren" is used throughout the Clippy codebase as an abbreviation for
"parentheses".

changelog: none
The `uninlined_format_args` was temporarily downgraded to `pedantic` in
part because rust-analyzer was not fully supporting it at the time, per
rust-lang#10087. The support has been added over [a year
ago](rust-lang/rust-analyzer#11260), so seems
like this should be back to style.

Another source of the initial frustration was fixed since then as well -
this lint does not trigger by default in case only some arguments can be
inlined.

changelog: [`uninlined_format_args`]: move back to `style`
Both lints share a lot of characteristics but were implemented in
unrelated ways. This unifies them, saving around 100 SLOC in the
process, and making one more test trigger the lint. Also, this removes
useless blocks in suggestions.
…ng#14332)

Both lints share a lot of characteristics but were implemented in
unrelated ways. This unifies them, saving around 100 SLOC in the
process, and making one more test trigger the lint. Also, this removes
useless blocks in suggestions.

Close rust-lang#12956

changelog: none
This lint does more harm than good: in its description, it proposes to
rewrite `match` on `Vec<_>` indexes or slices by a version which cannot
panic but masks the failure by choosing the default variant.

The `clippy::indexing_slicing` restriction lint covers those cases more
safely, by suggesting to use a non-panicking version to retrieve the
value from the container, without suggesting to fallback to the default
success variant in case of failure.
This PR enables the new ability to collapse `if` statements containing
comments (without losing them) in Clippy sources, excluding tests and
lintcheck, where the default behaviour (no collapsing in presence of
comments) is preserved.

To be applied after rust-lang#14231. When it is applied, rust-lang#14455 will be marked as
ready for review, then rust-lang#14228 afterwards.

changelog: none

r? ghost
…licit cast (rust-lang#14389)

Closes rust-lang#11059

changelog: `option_if_let_else`: fix wrong suggestion when coersion
requires explicit cast
Signed-off-by: todaymoon <[email protected]>
*Please write a short comment explaining your change (or "none" for
internal only changes)*

remove redundant words in comment

changelog: none
This extra condition prevents a problem when removing the '}' in:
```rust
  ( // There was an opening bracket after the parenthesis, which has been removed
    // This is a comment
   })
```
Removing the whitespaces, including the linefeed, before the '}', would put the
closing parenthesis at the end of the `// This is a comment` line, which would
make it part of the comment as well. In this case, it is best to keep the span
on the '}' alone.
…ust-lang#14480)

This extra condition prevents a problem when removing the '}' in:
```rust
  ( // There was an opening bracket after the parenthesis, which has been removed
    // This is a comment
   })
```
Removing the whitespaces, including the linefeed, before the '}', would
put the closing parenthesis at the end of the `// This is a comment`
line, which would make it part of the comment as well. In this case, it
is best to keep the span on the '}' alone.

changelog: none

Note to reviewer: `manual_inspect` and `collapsible_if` were two lints
exhibiting this problem in cooked up test cases, which have been
included as non-regression tests.
Dereferencing string literals in suggestions is redundant.

changelog: [`cmp_owned`]: more natural suggestions are provided for
string literals now

fixes rust-lang#8103
When lowering a destructuring assignment from AST to HIR, the compiler
will reuse the same identifier name (namely `sym::lhs`) for all the
fields. The desugaring must be checked for to avoid a false positive 
of the `shadow_unrelated` lint.
…4381)

When lowering a destructuring assignment from AST to HIR, the compiler
will reuse the same identifier name (namely `sym::lhs`) for all the
fields. The desugaring must be checked for to avoid a false positive of
the `shadow_unrelated` lint.

Fix rust-lang#10279
Fix rust-lang#14377

changelog: [`shadow_unrelated`]: prevent false positive in destructuring
assignments
@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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 22, 2025
@bors
Copy link
Collaborator

bors commented Apr 22, 2025

⌛ Testing commit 50a5793 with merge 59cd77d...

bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 22, 2025
…nishearth

Clippy subtree update

r? `@Manishearth`

Cargo.lock update due to the Clippy version bump and because Clippy moved from rinja (unmaintained) to askama.

Last sync was skipped due to the askama issue and me not getting to fixing this in time.
@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Collaborator

bors commented Apr 22, 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 Apr 22, 2025
@flip1995
Copy link
Member Author

Please let this be the last issue 😅

@Manishearth
Copy link
Member

@bors r+

@bors
Copy link
Collaborator

bors commented Apr 23, 2025

📌 Commit e8737e3 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 Apr 23, 2025
@bors
Copy link
Collaborator

bors commented Apr 23, 2025

⌛ Testing commit e8737e3 with merge df35ff6...

@bors
Copy link
Collaborator

bors commented Apr 23, 2025

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 23, 2025
@bors bors merged commit df35ff6 into rust-lang:master Apr 23, 2025
7 checks passed
@rustbot rustbot added this to the 1.88.0 milestone Apr 23, 2025
Copy link

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 553600e (parent) -> df35ff6 (this PR)

Test differences

No test diffs found

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard df35ff6c354f1f1fbf430b84e7dea37dfe997f34 --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-x86_64-linux: 5589.9s -> 5057.5s (-9.5%)
  2. dist-x86_64-musl: 8002.7s -> 7268.9s (-9.2%)
  3. x86_64-gnu-distcheck: 4328.8s -> 4707.3s (8.7%)
  4. i686-msvc-2: 7669.1s -> 7027.6s (-8.4%)
  5. dist-aarch64-apple: 5664.7s -> 5197.0s (-8.3%)
  6. dist-i686-mingw: 8042.9s -> 8660.5s (7.7%)
  7. dist-x86_64-mingw: 7640.6s -> 8157.6s (6.8%)
  8. dist-x86_64-apple: 10775.8s -> 10084.1s (-6.4%)
  9. x86_64-mingw-1: 9518.6s -> 8954.6s (-5.9%)
  10. i686-gnu-2: 6459.4s -> 6738.4s (4.3%)
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 (df35ff6): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
0.2% [0.2%, 0.2%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.2% [-0.3%, -0.1%] 7
Improvements ✅
(secondary)
-0.3% [-0.6%, -0.2%] 36
All ❌✅ (primary) -0.1% [-0.3%, 0.2%] 8

Max RSS (memory usage)

Results (primary -1.4%, secondary 1.8%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.6% [0.6%, 0.6%] 1
Regressions ❌
(secondary)
5.5% [3.0%, 8.4%] 4
Improvements ✅
(primary)
-2.1% [-2.5%, -1.3%] 3
Improvements ✅
(secondary)
-1.8% [-2.0%, -1.6%] 4
All ❌✅ (primary) -1.4% [-2.5%, 0.6%] 4

Cycles

Results (primary 0.6%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Binary size

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

Bootstrap: 775.751s -> 775.888s (0.02%)
Artifact size: 364.98 MiB -> 365.06 MiB (0.02%)

@rustbot rustbot added the perf-regression Performance regression. label Apr 23, 2025
@nnethercote
Copy link
Contributor

The perf improvements greatly outweigh the few regressions.

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Apr 23, 2025
@flip1995 flip1995 deleted the clippy-subtree-update branch April 24, 2025 10:55
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. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. 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)
Projects
None yet
Development

Successfully merging this pull request may close these issues.