Skip to content

Rollup of 10 pull requests #144624

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 33 commits into from
Jul 29, 2025
Merged

Rollup of 10 pull requests #144624

merged 33 commits into from
Jul 29, 2025

Conversation

Zalathar
Copy link
Contributor

@Zalathar Zalathar commented Jul 29, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

shepmaster and others added 30 commits July 23, 2025 11:35
`macos-13` is going away soonish.
Co-authored-by: lcnr <rust@lcnr.de>
Co-authored-by: Ralf Jung <post@ralfj.de>
Co-authored-by: waffle <waffle.lapkin@gmail.com>
- Address Call for Testing review feedback
- Address Affiliated work review feedback
- Drop "stabilization is easy" part
- Fix broken feature gate examples
- Elaborate on stabilization report summarization aspects
- Recommend waiting a bit for team nominations
- Make Stabilization Template markdown copy friendly
- Register stabilization report template
- Drop unfinished sentence
- Clarify stabilization report template is for language features
- Add test coverage elaboration
- Add UB checks / opt question
- Amend test coverage explanation
- Mention OSS nightly users
Let's revise both the new content in this PR as well as the remaining
text in the relevant chapters so as to better describe our current
processes related to language features and their stabilizations.

For the new stabilization report template, based on reviewing its
early use and well as reviewing earlier stabilization reports, we've
revised it editorially and added questions designed to capture
additional details to which we commonly want people to speak.
This updates the rust-version file to 2b5e239.
Pull recent changes from https://github.com/rust-lang/rust via Josh.

Upstream ref: 2b5e239
Filtered ref: dde2393b3444ae8595633863f4395f526b1b7932

This merge was created using https://github.com/rust-lang/josh-sync.
Fix CI for drop_guard

fix CI

fix all tidy lints

fix tidy link

add first batch of feedback from review

Add second batch of feedback from review

add third batch of feedback from review

fix failing test

Update library/core/src/mem/drop_guard.rs

Co-authored-by: Ruby Lazuli <general@patchmixolydic.com>

fix doctests

Implement changes from T-Libs-API review

And start tracking based on the tracking issue.

fix tidy lint
The bug was triggered by a particular usage of the `?` try operator in a
proc-macro expansion.

Thanks to lqd for the minimization.

Co-authored-by: Rémy Rakic <remy.rakic+github@gmail.com>
…target, r=ehuss

Add `--link-targets-dir` argument to linkchecker

In my release notes API list tool (rust-lang#143053) I want to check whether all links generated by the tool are actually valid, and using linkchecker seems to be the most sensible choice.

Linkchecker currently has a fairly big limitation though: it can only check a single directory, it checks *all* of the files within it, and link targets must point inside that same directory. This works great when checking the whole documentation package, but in my case I only need to check that one file contains valid links to the standard library docs.

To solve that, this PR adds a new `--link-targets-dir` flag to linkchecker. Directories passed to it will be valid link targets (with lower priority than the root being checked), but links within them will not be checked.

I'm not that happy with the name of the flag, happy for it to be bikeshedded.
…ulacrum

Add `core::mem::DropGuard`

## 1.0 Summary

This PR introduces a new type `core::mem::DropGuard` which wraps a value and runs a closure when the value is dropped.

```rust
use core::mem::DropGuard;

// Create a new guard around a string that will
// print its value when dropped.
let s = String::from("Chashu likes tuna");
let mut s = DropGuard::new(s, |s| println!("{s}"));

// Modify the string contained in the guard.
s.push_str("!!!");

// The guard will be dropped here, printing:
// "Chashu likes tuna!!!"
```

## 2.0 Motivation

A number of programming languages include constructs like `try..finally` or `defer` to run code as the last piece of a particular sequence, regardless of whether an error occurred. This is typically used to clean up resources, like closing files, freeing memory, or unlocking resources. In Rust we use the `Drop` trait instead, allowing us to [never having to manually close sockets](https://blog.skylight.io/rust-means-never-having-to-close-a-socket/).

While `Drop` (and RAII in general) has been working incredibly well for Rust in general, sometimes it can be a little verbose to setup. In particular when upholding invariants are local to functions, having a quick inline way to setup an `impl Drop` can be incredibly convenient. We can see this in use in the Rust stdlib, which has a number of private `DropGuard` impls used internally:

- [library/alloc/src/vec/drain.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/vec/drain.rs#L177)
- [library/alloc/src/boxed/thin.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/boxed/thin.rs#L362)
- [library/alloc/src/slice.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/slice.rs#L413)
- [library/alloc/src/collections/linked_list.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/collections/linked_list.rs#L1135)
- [library/alloc/src/collections/binary_heap/mod.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/collections/binary_heap/mod.rs#L1816)
- [library/alloc/src/collections/btree/map.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/collections/btree/map.rs#L1715)
- [library/alloc/src/collections/vec_deque/drain.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/collections/vec_deque/drain.rs#L95)
- [library/alloc/src/vec/into_iter.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/alloc/src/vec/into_iter.rs#L488)
- [library/std/src/os/windows/process.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/library/std/src/os/windows/process.rs#L320)
- [tests/ui/process/win-proc-thread-attributes.rs](https://github.com/rust-lang/rust/blob/9982d6462bedf1e793f7b2dbd655a4e57cdf67d4/tests/ui/process/win-proc-thread-attributes.rs#L17)

## 3.0 Design

This PR implements what can be considered about the simplest possible design:

1. A single type `DropGuard` which takes both a generic type `T` and a closure `F`.
2. `Deref` + `DerefMut` impls to make it easy to work with the `T` in the guard.
3. An `impl Drop` on the guard which calls the closure `F` on drop.
4. An inherent `fn into_inner` which takes the type `T` out of the guard without calling the closure `F`.

Notably this design does not allow divergent behavior based on the type of drop that has occurred. The [`scopeguard` crate](https://docs.rs/scopeguard/latest/scopeguard/index.html) includes additional `on_success` and `on_onwind` variants which can be used to branch on unwind behavior instead. However [in a lot of cases](rust-lang#143612 (comment)) this doesn’t seem necessary, and using the arm/disarm pattern seems to provide much the same functionality:

```rust
let guard = DropGuard::new((), |s| ...);  // 1. Arm the guard
other_function();                         // 2. Perform operations
guard.into_inner();                       // 3. Disarm the guard
```

`DropGuard` combined with this pattern seems like it should cover the vast majority of use cases for quick, inline destructors. It certainly seems like it should cover all existing uses in the stdlib, as well as all existing uses in crates like [hashbrown](https://github.com/search?q=repo%3Arust-lang%2Fhashbrown%20guard&type=code).

## 4.0 Acknowledgements

This implementation is based on the [mini-scopeguard crate](https://github.com/yoshuawuyts/mini-scopeguard) which in turn is based on the [scopeguard  crate](https://docs.rs/scopeguard). The implementations only differ superficially; because of the nature of the problem there is only really one obvious way to structure the solution. And the scopeguard crate got that right!

## 5.0 Conclusion

This PR adds a new type `core::mem::DropGuard` to the stdlib which adds a small convenience helper to create inline destructors with. This would bring the majority of the functionality of the `scopeguard` crate into the stdlib, which is the [49th most downloaded crate](https://crates.io/crates?sort=downloads) on crates.io (387 million downloads).

Given the actual implementation of `DropGuard` is only around 60 lines, it seems to hit that sweet spot of low-complexity / high-impact that makes for a particularly efficient stdlib addition. Which is why I’m putting this forward for consideration; thanks!
…-usage, r=Mark-Simulacrum

Move dist-apple-various from x86_64 to aarch64

`macos-13` is going away soonish.
…ance, r=oli-obk

constify with_exposed_provenance

We allow `int as ptr` in const, so it only makes sense to also allow this function. Otherwise, `const fn` can't be ported to use the more explicit exposed provenance APIs.

Note that as of today, `with_exposed_provenance` in const is equivalent to `without_provenance`. However, we probably don't want to promise that: if someone does `with_exposed_provenance(MMIO_ADDR)` in const and then uses that pointer at runtime, that is something we should ensure keeps working; if someone does the same with `without_provenance` then I would consider that UB.

Tracking: rust-lang#144538
Cc `````@rust-lang/wg-const-eval````` `````@rust-lang/opsem`````
rustc-dev-guide subtree update

Subtree update of `rustc-dev-guide` to rust-lang/rustc-dev-guide@e19866a.

Created using https://github.com/rust-lang/josh-sync.

r? `````@ghost`````
… r=lcnr

Raw Pointers are Constant PatKinds too

raw pointers can be matched on with a const pattern:
```rust
const FOO: *const u8 = core::ptr::null();

fn foo(a: *const u8) {
  match a {
    FOO => (),
    _ => todo!(),
  }
}
```
as far as I can tell this is represented with a `PatKind::Constant`: https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_build/src/thir/pattern/const_to_pat.rs#L333-L337
fixed typo chunks->as_chunks

Fixes rust-lang#144555

info-:
fix typo chunks -> as_chunks

This now take us to as_chunks page when clicking on as_chunks link and not to chunks .

Thanks .
Zalathar added 3 commits July 29, 2025 16:16
…rors

Ensure correct aligement of rustc_hir::Lifetime on platforms with lower default alignments.

The compiler relies on `hir::Lifetime` being aligned to at least 4 bytes(for the purposes of pointer tagging).

However, on some systems(like m68k) with lower alignment requirements(eg. usize / u32 aligned to 2 bytes),`hir::Lifetime` will be aligned to only 2 bytes.

This causes the compilation to fail on those systems - a const assert in the compiler fails.

This PR makes the aligement requriement of hir::Lifetime explict. This has no effect on platforms where that already is the case(repr align can only raise alignment), but ensures the alignment will stay correct no matter what.
fix `Atomic*::as_ptr` wording

r? `````@RalfJung`````

cc rust-lang#144072
coverage: Regression test for "function name is empty" bug

Regression test for rust-lang#141577, which was triggered by rust-lang#144298.

The bug was triggered by a particular usage of the `?` try operator in a proc-macro expansion.

Thanks to lqd for the minimization at rust-lang#144571 (comment).

---

I have manually verified that reverting the relevant follow-up fixes (rust-lang#144480 and rust-lang#144530) causes this test to reproduce the bug:

```sh
git revert -m1 8aa3d41 c462895
```

---

r? compiler
@rustbot rustbot added A-CI Area: Our Github Actions CI A-rustc-dev-guide Area: rustc-dev-guide A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jul 29, 2025
@Zalathar
Copy link
Contributor Author

@bors r+ rollup=never p=5

@bors
Copy link
Collaborator

bors commented Jul 29, 2025

📌 Commit cac55bd has been approved by Zalathar

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 29, 2025
@Zalathar
Copy link
Contributor Author

This is a subset of #144622.

@bors
Copy link
Collaborator

bors commented Jul 29, 2025

⌛ Testing commit cac55bd with merge 5529041...

@bors
Copy link
Collaborator

bors commented Jul 29, 2025

☀️ Test successful - checks-actions
Approved by: Zalathar
Pushing 5529041 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jul 29, 2025
@bors bors merged commit 5529041 into rust-lang:master Jul 29, 2025
11 checks passed
@rustbot rustbot added this to the 1.90.0 milestone Jul 29, 2025
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#143883 Add --link-targets-dir argument to linkchecker e11da266e4a8cf583033dd53f1330ace32cd002e (link)
#144236 Add core::mem::DropGuard a0afbc16961523d0cfdfd42b423d479a4b6280f7 (link)
#144367 Move dist-apple-various from x86_64 to aarch64 d9a7c6e07a195939c95ff8e9910baf90f1497e77 (link)
#144539 constify with_exposed_provenance 67e0b0f991c5dd01ac32df5c627264da986da351 (link)
#144569 rustc-dev-guide subtree update 72c304d763c7245a9dd0314032d840603b6162a0 (link)
#144573 Raw Pointers are Constant PatKinds too e8680204f493a89db7c5865eea79b05fe3ff3965 (link)
#144575 fixed typo chunks->as_chunks c647f3bdcba3a6475c592683c0b3a7509233196e (link)
#144578 Ensure correct aligement of rustc_hir::Lifetime on platform… 3572f9ab45950d6163b775b5c1561c92d048dfdf (link)
#144582 fix Atomic*::as_ptr wording a0e1ee25d0e281e7337e7b3e542e8d1f049a4f09 (link)
#144616 coverage: Regression test for "function name is empty" bug 8850828928faf28d509419df235fc33ae87c8c84 (link)

previous master: cb6785f73d

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

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 cb6785f (parent) -> 5529041 (this PR)

Test differences

Show 188 test diffs

Stage 1

  • [coverage-map] tests/coverage/try-in-macro.rs#attr: [missing] -> pass (J0)
  • [coverage-map] tests/coverage/try-in-macro.rs#bang: [missing] -> pass (J0)
  • [coverage-map] tests/coverage/try-in-macro.rs#derive: [missing] -> pass (J0)
  • [coverage-run] tests/coverage/try-in-macro.rs#attr: [missing] -> ignore (ignored when the profiler runtime is not available) (J0)
  • [coverage-run] tests/coverage/try-in-macro.rs#bang: [missing] -> ignore (ignored when the profiler runtime is not available) (J0)
  • [coverage-run] tests/coverage/try-in-macro.rs#derive: [missing] -> ignore (ignored when the profiler runtime is not available) (J0)
  • mem::drop_guard_always_drops_value_if_closure_drop_unwinds: [missing] -> pass (J1)
  • mem::drop_guard_into_inner: [missing] -> pass (J1)
  • mem::drop_guards_only_dropped_by_closure_when_run: [missing] -> pass (J1)

Stage 2

  • [coverage-run] tests/coverage/try-in-macro.rs#attr: [missing] -> ignore (ignored when the profiler runtime is not available) (J2)
  • [coverage-run] tests/coverage/try-in-macro.rs#bang: [missing] -> ignore (ignored when the profiler runtime is not available) (J2)
  • [coverage-run] tests/coverage/try-in-macro.rs#derive: [missing] -> ignore (ignored when the profiler runtime is not available) (J2)
  • [coverage-run] tests/coverage/try-in-macro.rs#attr: [missing] -> pass (J3)
  • [coverage-run] tests/coverage/try-in-macro.rs#bang: [missing] -> pass (J3)
  • [coverage-run] tests/coverage/try-in-macro.rs#derive: [missing] -> pass (J3)
  • [coverage-run] tests/coverage/try-in-macro.rs#attr: [missing] -> ignore (ignored when cross-compiling) (J4)
  • [coverage-run] tests/coverage/try-in-macro.rs#bang: [missing] -> ignore (ignored when cross-compiling) (J4)
  • [coverage-run] tests/coverage/try-in-macro.rs#derive: [missing] -> ignore (ignored when cross-compiling) (J4)
  • [coverage-map] tests/coverage/try-in-macro.rs#attr: [missing] -> pass (J5)
  • [coverage-map] tests/coverage/try-in-macro.rs#bang: [missing] -> pass (J5)
  • [coverage-map] tests/coverage/try-in-macro.rs#derive: [missing] -> pass (J5)

Additionally, 167 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 552904134b564a74489db50aebe7070fdcce895c --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-aarch64-apple: 9929.5s -> 5934.3s (-40.2%)
  2. dist-apple-various: 8029.6s -> 5383.4s (-33.0%)
  3. aarch64-apple: 6160.4s -> 4281.8s (-30.5%)
  4. dist-x86_64-apple: 9855.1s -> 7377.5s (-25.1%)
  5. x86_64-gnu-llvm-19: 2956.5s -> 2471.7s (-16.4%)
  6. pr-check-2: 2696.9s -> 2297.4s (-14.8%)
  7. i686-gnu-2: 6266.4s -> 5386.8s (-14.0%)
  8. i686-gnu-nopt-1: 8040.4s -> 7132.5s (-11.3%)
  9. x86_64-rust-for-linux: 2909.3s -> 2585.7s (-11.1%)
  10. x86_64-gnu-debug: 6113.5s -> 5509.6s (-9.9%)
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.

@Zalathar Zalathar deleted the rollup-w803jmq branch July 29, 2025 09:30
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (5529041): 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)

Results (primary 0.6%, secondary -2.3%)

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

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

Cycles

Results (secondary -0.5%)

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)
3.5% [2.6%, 4.4%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-3.2% [-3.5%, -2.5%] 3
All ❌✅ (primary) - - 0

Binary size

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

Bootstrap: 467.912s -> 468.885s (0.21%)
Artifact size: 376.82 MiB -> 376.79 MiB (-0.01%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-CI Area: Our Github Actions CI A-rustc-dev-guide Area: rustc-dev-guide A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup 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-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.