Skip to content

Clippy subtree update #143745

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 119 commits into from
Jul 14, 2025
Merged

Clippy subtree update #143745

merged 119 commits into from
Jul 14, 2025

Conversation

flip1995
Copy link
Member

@flip1995 flip1995 commented Jul 10, 2025

r? @Manishearth

Cargo.lock update due to ui_test bump and restructure.

Alexendoo and others added 30 commits May 16, 2025 01:07
The `TyCtxt::hir_get_fn_id_for_return_block()` function was too broad,
as it will return positively even when given part of an expression that can
be used as a return value. A new `potential_return_of_enclosing_body()`
utility function has been made to represent the fact that an expression
might be directly returned from its enclosing body.
This commit also adds more test cases, which work fine but were
mentioned in the issue.
…links-expansion, r=lolbinarycat

[rustdoc] Do not emit redundant_explicit_links lint if the doc comment comes from expansion

Fixes rust-lang#141553.

The problem was that we change the context for the attributes in some cases to get better error output, preventing us to detect if the attribute comes from expansion. Most of the changes are about keeping track of the "does this span comes from expansion" information.

r? ```@Manishearth```
The lint was extra restrictive, and didn't suggest using
`core::ptr::null` and `core::ptr::null_mut` in `const` contexts although
they have been const-stabilized since Rust 1.24.
…=fee1-dead

New const traits syntax

This PR only affects the AST and doesn't actually change anything semantically.

All occurrences of `~const` outside of libcore have been replaced by `[const]`. Within libcore we have to wait for rustfmt to be bumped in the bootstrap compiler. This will happen "automatically" (when rustfmt is run) during the bootstrap bump, as rustfmt converts `~const` into `[const]`. After this we can remove the `~const` support from the parser

Caveat discovered during impl: there is no legacy bare trait object recovery for `[const] Trait` as that snippet in type position goes down the slice /array parsing code and will error

r? ``@fee1-dead``

cc ``@nikomatsakis`` ``@traviscross`` ``@compiler-errors``
…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#139858 (New const traits syntax)
 - rust-lang#140809 (Reduce special casing for the panic runtime)
 - rust-lang#142730 (suggest declaring modules when file found but module not defined)
 - rust-lang#142806 (Normalize before computing ConstArgHasType goal in new solver)
 - rust-lang#143046 (const validation: properly ignore zero-sized UnsafeCell)
 - rust-lang#143092 (const checks for lifetime-extended temporaries: avoid 'top-level scope' terminology)
 - rust-lang#143096 (tag_for_variant: properly pass TypingEnv)
 - rust-lang#143104 (hir_analysis: prohibit `dyn PointeeSized`)
 - rust-lang#143106 (gce: don't ICE on non-local const)

Failed merges:

 - rust-lang#143036 (Remove support for `dyn*` from the compiler)

r? `@ghost`
`@rustbot` modify labels: rollup
The lint was extra restrictive, and didn't suggest using
`core::ptr::null` and `core::ptr::null_mut` in `const` contexts although
they have been const-stabilized since Rust 1.24.

changelog: [`zero_ptr`]: lint in `const` context as well

@rustbot label +I-false-negative +C-bug
…15123)

Closes rust-lang/rust-clippy#15116

The cause for this issue is that `_` belongs to the `Common` catagory in
unicode instead of `Latin` like other ASCII alphabets. Since ASCII
characters are always allowed, I just added an extra `is_ascii()` check
to ensure this.

changelog: [`disallowed_script_idents`] fix FP on identifiers with `_`
@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 10, 2025
@rust-log-analyzer

This comment has been minimized.

@RalfJung
Copy link
Member

RalfJung commented Jul 12, 2025

Ah

2025-07-12T09:34:41.1952415Z full stderr:
2025-07-12T09:34:41.1963726Z error: failed to write /checkout/src/tools/clippy/clippy_test_deps/Cargo.lock
2025-07-12T09:34:41.1963785Z 
2025-07-12T09:34:41.1963914Z Caused by:
2025-07-12T09:34:41.1964233Z   failed to open: /checkout/src/tools/clippy/clippy_test_deps/Cargo.lock
2025-07-12T09:34:41.1964246Z 
2025-07-12T09:34:41.1964368Z Caused by:
2025-07-12T09:34:41.1964525Z   Read-only file system (os error 30)

So we do need rust-lang/rust-clippy#15255 in this PR, it can't land separately.

@RalfJung RalfJung force-pushed the clippy-subtree-update branch from 4bc379d to a0a8e80 Compare July 12, 2025 10:10
@samueltardieu
Copy link
Contributor

Looks like @RalfJung commits now allow the PR to build. @flip1995 any blocker left on your side?

@flip1995 flip1995 marked this pull request as ready for review July 14, 2025 16:18
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 14, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jul 14, 2025

The Miri subtree was changed

cc @rust-lang/miri

@rustbot

This comment was marked as off-topic.

@flip1995
Copy link
Member Author

Yes, should be good now. Thanks for looking into and fixing this @RalfJung ! (Just got back from my long weekend vacation)

@Manishearth
Copy link
Member

@bors r+

@bors
Copy link
Collaborator

bors commented Jul 14, 2025

📌 Commit a0a8e80 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 14, 2025
@matthiaskrgr
Copy link
Member

@bors p=1 subtree sync

@samueltardieu
Copy link
Contributor

@Manishearth Given that this PR also touches dependencies and workspaces, maybe it would be safer to make it rollup=never

@RalfJung
Copy link
Member

@bors rollup=never

@bors
Copy link
Collaborator

bors commented Jul 14, 2025

⌛ Testing commit a0a8e80 with merge a001497...

Kobzol added a commit to Kobzol/rust that referenced this pull request Jul 14, 2025
…Manishearth

Clippy subtree update

r? `@Manishearth`

Cargo.lock update due to `ui_test` bump and restructure.
@bors
Copy link
Collaborator

bors commented Jul 14, 2025

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 14, 2025
@bors bors merged commit a001497 into rust-lang:master Jul 14, 2025
12 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jul 14, 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 aa51a9b (parent) -> a001497 (this PR)

Test differences

No test diffs found

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard a001497644bc229f1abcc5b2528733386591647f --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: 6528.8s -> 9048.0s (38.6%)
  2. x86_64-apple-1: 5594.6s -> 7490.2s (33.9%)
  3. dist-aarch64-linux: 8588.3s -> 6071.9s (-29.3%)
  4. dist-x86_64-apple: 8611.9s -> 10317.8s (19.8%)
  5. dist-x86_64-msvc: 6186.0s -> 6929.7s (12.0%)
  6. x86_64-gnu-llvm-20-1: 3330.7s -> 3702.2s (11.2%)
  7. x86_64-apple-2: 4555.8s -> 5015.3s (10.1%)
  8. dist-aarch64-apple: 6054.1s -> 6595.5s (8.9%)
  9. aarch64-gnu: 6190.2s -> 6726.5s (8.7%)
  10. x86_64-msvc-ext3: 5846.9s -> 6350.3s (8.6%)
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 (a001497): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

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

Cycles

Results (primary 2.9%, secondary 2.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
2.9% [2.9%, 2.9%] 1
Regressions ❌
(secondary)
2.1% [2.1%, 2.1%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.9% [2.9%, 2.9%] 1

Binary size

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

Bootstrap: 463.338s -> 464.247s (0.20%)
Artifact size: 374.73 MiB -> 374.71 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)
Projects
None yet
Development

Successfully merging this pull request may close these issues.