Merge subtree update for toolchain nightly-2025-08-26 #480
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…manieu Document Poisoning in `LazyCell` and `LazyLock` Currently, there is no documentation of poisoning behavior in either `LazyCell` or `LazyLock`, even though both of them can be observed as poisoned by users. `LazyCell` [plagyround example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=9cf38b8dc56db100848f54085c2c697d) `LazyLock` [playground example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=f1cd6f9fe16636e347ebb695a0ce30c0) # Open Questions - [x] Is it worth making the implementation of `LazyLock` more complicated to ensure that the the panic message is `"LazyLock instance has previously been poisoned"` instead of `"Once instance has previously been poisoned"`? See the `LazyLock` playground link above for more context. - [x] Does it make sense to move `LazyLock` into the `poison` module? It is certainly a poison-able type, but at the same time it is slightly different from the 4 other types currently in the `poison` module in that it is unrecoverable. I think this is more of a libs-api question. ``@rustbot`` label +T-libs-api Please let me know if these open questions deserve a separate issue / PR!
Changes: 1. Removed `from_c` from the IntrinsicType definition. 2. Moved the `from_c` arm-specific definition to an ArmIntrinsicType-specific impl block
…-test-intrinsictype-cleanup `intrinsic-test`: Cleaning the `IntrinsicType` struct and related functionalities
Add dynamic support for aarch64 LSE atomic ops on linux targets when optimized-compiler-builtins is not enabled. A hook, __enable_rust_lse, is provided for the runtime to enable them if available. A future patch will use this to enable them if available. The resulting asm should exactly match that of LLVM's compiler-rt builtins, though the symbol naming for the support function and global does not.
Create a private module to hold the bootstrap code needed enable LSE at startup on aarch64-*-linux-* targets when rust implements the intrinsics. This is a bit more heavyweight than compiler-rt's LSE initialization, but has the benefit of initializing the aarch64 cpu feature detection for other uses. Using the rust initialization code does use some atomic operations, that's OK. Mixing LSE and non-LSE operations should work while the update flag propagates.
Like its signed counterpart, this function does not panic. Also, fix the examples to document how it returns Some/None.
libs-api has agreed to rename these functions to `isolate_highest_one`/`isolate_lowest_one`
… of a file, not an extension
Currently we run the `rustc` from the `RUSTC` environment variable to
figure out whether or not to enable `f16` and `f128`, based on the
`target_has_reliable_{f16,f128}` config. However, this does not know
about the codegen backend used, and the backend isn't trivial to check
in a build script (usually it gets set via `RUSTFLAGS`).
It turns out we don't actually need to run `rustc` here: Cargo
unconditionally emits all config from the relevant compiler as
`CARGO_CFG_*` variables, regardless of whether or not they are known
options. Switch to checking these for setting config rather than
invoking `rustc`.
As an added advantage, this will work with target.json files without any
special handling.
Fixes: ed17b95715dd ("Use the compiler to determine whether or not to enable `f16` and `f128`")
…on directories Inspired by rust-lang#123883 .
This fixes a few intrinsic docs that had a link directly to itself instead of to the correct function in the `mem` module.
Change visibility of Args new function Currently the Args new function is constrained to pub(super) but this stops me from being able to construct Args structs in unit tests. This pull request is to change this to pub.
…iper Correct the use of `must_use` on btree::IterMut I'm working on stricter target checking for attributes and found this one
…htriplett num: Rename `isolate_most_least_significant_one` functions Tracking issue - rust-lang#136909 libs-api has agreed to rename these unstable functions to `isolate_highest_one`/`isolate_lowest_one` rust-lang#136909 (comment) `isolate_most_significant_one` -> `isolate_highest_one` `isolate_least_significant_one` -> `isolate_lowest_one`
Fix some doc links for intrinsics This fixes a few intrinsic docs that had a link directly to itself instead of to the correct function in the `mem` module.
…on, r=ChrisDenton Stabilize `panic_payload_as_str` feature Closes [tracking issue](rust-lang#125175). Part of rust-lang#116005. FCP ended more than year ago in tracking issue, I'm not sure if we should rerun it.
…iplett add code example showing that file_prefix treats dotfiles as the name of a file, not an extension This came up in a libs-api meeting while we were reviewing rust-lang#144870
…ratt `File::set_times`: Update documentation and example to support setting timestamps on directories Inspired by rust-lang#123883 .
…ark-Simulacrum UnsafePinned::raw_get: sync signature with get This was forgotten in rust-lang#142162. Tracking issue: rust-lang#125735.
…triplett Add flock support for cygwin See discussion: rust-lang#145534 (comment) cc: ``@jeremyd2019``
Fix typo in docstring The return type is correct in the source code but incorrect in the docstring.
Consolidate all the panicking functions in `slice/index.rs` to use a single `slice_index_fail` function, similar to how it is done in `str/traits.rs`.
miri subtree update Subtree update of `miri` to rust-lang/miri@980da67. Created using https://github.com/rust-lang/josh-sync. r? `@ghost`
libstd: init(): dup() subsequent /dev/nulls instead of opening them again
This will be faster, and also it deduplicates the code so win/win
The dup() is actually infallible here. But whatever.
Before:
```
poll([{fd=0, events=0}, {fd=1, events=0}, {fd=2, events=0}], 3, 0) = 1 ([{fd=2, revents=POLLNVAL}])
openat(AT_FDCWD, "/dev/null", O_RDWR) = 2
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f5749313050}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
poll([{fd=0, events=0}, {fd=1, events=0}, {fd=2, events=0}], 3, 0) = 2 ([{fd=0, revents=POLLNVAL}, {fd=2, revents=POLLNVAL}])
openat(AT_FDCWD, "/dev/null", O_RDWR) = 0
openat(AT_FDCWD, "/dev/null", O_RDWR) = 2
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7efe12006050}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
poll([{fd=0, events=0}, {fd=1, events=0}, {fd=2, events=0}], 3, 0) = 3 ([{fd=0, revents=POLLNVAL}, {fd=1, revents=POLLNVAL}, {fd=2, revents=POLLNVAL}])
openat(AT_FDCWD, "/dev/null", O_RDWR) = 0
openat(AT_FDCWD, "/dev/null", O_RDWR) = 1
openat(AT_FDCWD, "/dev/null", O_RDWR) = 2
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fc2dc7ca050}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
```
After:
```
poll([{fd=0, events=0}, {fd=1, events=0}, {fd=2, events=0}], 3, 0) = 1 ([{fd=1, revents=POLLNVAL}])
openat(AT_FDCWD, "/dev/null", O_RDWR) = 1
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f488a3fb050}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
poll([{fd=0, events=0}, {fd=1, events=0}, {fd=2, events=0}], 3, 0) = 2 ([{fd=1, revents=POLLNVAL}, {fd=2, revents=POLLNVAL}])
openat(AT_FDCWD, "/dev/null", O_RDWR) = 1
dup(1) = 2
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f1a8943c050}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
poll([{fd=0, events=0}, {fd=1, events=0}, {fd=2, events=0}], 3, 0) = 3 ([{fd=0, revents=POLLNVAL}, {fd=1, revents=POLLNVAL}, {fd=2, revents=POLLNVAL}])
openat(AT_FDCWD, "/dev/null", O_RDWR) = 0
dup(0) = 1
dup(0) = 2
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f4e3a4c7050}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
```
…nicking, r=jhpratt Consolidate panicking functions in `slice/index.rs` Consolidate all the panicking functions in `slice/index.rs` to use a single `slice_index_fail` function, similar to how it is done in `str/traits.rs`. Split off from rust-lang#145024
…iplett Migrate `panic_unwind` to use `cfg_select!` This follows rust-lang#145489 with an additional place we can drop the `cfg-if` dependency.
Fixes an issue where if the underlying `Once` panics because it is poisoned, the panic displays the wrong message. Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Fix overly restrictive lifetime in `core::panic::Location::file` return type Fixes rust-lang#131770 by relaxing the lifetime to match what's stored in the struct. See that issue for more details and discussion. Since this is a breaking change, I think a crater run is in order. Since this change should only have an effect at compile-time, I think just a check run is sufficient.
…ark-Simulacrum Implementation: `#[feature(nonpoison_rwlock)]` Tracking Issue: rust-lang#134645 This PR continues the effort made in rust-lang#144022 by adding the implementation of `nonpoison::rwlock`. Many of the changes here are similar to the changes made to implement `nonpoison::mutex`. The only real difference is that this PR includes a reorganizing of the existing `poison::rwlock` file that hopefully makes both variants more readable. ### Related PRs - `nonpoison_condvar` implementation: rust-lang#144651 - `nonpoison_once` implementation: rust-lang#144653
Fix some typos in LocalKey documentation A few minor grammatical/wording changes in the `std::thread::LocalKey` documentation.
… r=petrochenkov Experiment: Reborrow trait Tracking issue: rust-lang#145612 Starting off really small here: just introduce the unstable feature and the feature gate, and one of the two traits that the Reborrow experiment deals with. ### Cliff-notes explanation The `Reborrow` trait is conceptually a close cousin of `Copy` with the exception that it disables the source (`self`) for the lifetime of the target / result of the reborrow action. It can be viewed as a method of `fn reborrow(self: Self<'a>) -> Self<'a>` with the compiler adding tracking of the resulting `Self<'a>` (or any value derived from it that retains the `'a` lifetime) to keep the `self` disabled for reads and writes. No method is planned to be surfaced to the user, however, as reborrowing cannot be seen in code (except for method calls [`a.foo()` reborrows `a`] and explicit reborrows [`&*a`]) and thus triggering user-code in it could be viewed as "spooky action at a distance". Furthermore, the added compiler tracking cannot be seen on the method itself, violating the Golden Rule. Note that the userland "reborrow" method is not True Reborrowing, but rather a form of a "Fancy Deref": ```rust fn reborrow(&'short self: Self<'long>) -> Self<'short>; ``` The lifetime shortening is the issue here: a reborrowed `Self` or any value derived from it is bound to the method that called `reborrow`, since `&'short` is effectively a local variable. True Reborrowing does not shorten the lifetime of the result. To avoid having to introduce new kinds of references, new kinds of lifetime annotations, or a blessed trait method, no method will be introduced at all. Instead, the `Reborrow` trait is intended to be a derived trait that effectively reborrows each field individually; `Copy` fields end up just copying, while fields that themselves `Reborrow` get disabled in the source, usually leading to the source itself being disabled (some differences may appear with structs that contain multiple reborrowable fields). The goal of the experiment is to determine how the actual implementation here will shape out, and what the "bottom case" for the recursive / deriving `Reborrow` is. `Reborrow` has a friend trait, `CoerceShared`, which is equivalent to a `&'a mut T -> &'a T` conversion. This is needed as a different trait and different operation due to the different semantics it enforces on the source: a `CoerceShared` operation only disables the source for writes / exclusive access for the lifetime of the result. That trait is not yet introduced in this PR, though there is no particular reason why it could not be introduced.
Weekly `cargo update` (with libc pin) Supersedes rust-lang#145516 Manually pins libc for `compiler` and `rustbook` (both of which use rustix), with fixmes to remove this later. ``` compiler & tools dependencies: Locking 28 packages to latest compatible versions Updating anyhow v1.0.98 -> v1.0.99 Updating bitflags v2.9.1 -> v2.9.2 Updating clap v4.5.43 -> v4.5.45 Updating clap_builder v4.5.43 -> v4.5.44 Updating clap_derive v4.5.41 -> v4.5.45 Updating curl v0.4.48 -> v0.4.49 Updating curl-sys v0.4.82+curl-8.14.1 -> v0.4.83+curl-8.15.0 Updating cxx v1.0.166 -> v1.0.168 Updating cxx-build v1.0.166 -> v1.0.168 Updating cxxbridge-cmd v1.0.166 -> v1.0.168 Updating cxxbridge-flags v1.0.166 -> v1.0.168 Updating cxxbridge-macro v1.0.166 -> v1.0.168 Updating glob v0.3.2 -> v0.3.3 Updating object v0.37.2 -> v0.37.3 Updating proc-macro2 v1.0.95 -> v1.0.101 Updating rayon v1.10.0 -> v1.11.0 Updating rayon-core v1.12.1 -> v1.13.0 Updating serde-untagged v0.1.7 -> v0.1.8 Updating socket2 v0.5.10 -> v0.6.0 Updating syn v2.0.104 -> v2.0.106 Updating thiserror v2.0.12 -> v2.0.15 Updating thiserror-impl v2.0.12 -> v2.0.15 Updating uuid v1.17.0 -> v1.18.0 Updating wasm-encoder v0.236.0 -> v0.236.1 Updating wasmparser v0.236.0 -> v0.236.1 Updating wast v236.0.0 -> v236.0.1 Updating wat v1.236.0 -> v1.236.1 note: pass `--verbose` to see 35 unchanged dependencies behind latest library dependencies: Locking 2 packages to latest compatible versions Updating libc v0.2.174 -> v0.2.175 Updating object v0.37.2 -> v0.37.3 note: pass `--verbose` to see 2 unchanged dependencies behind latest rustbook dependencies: Locking 13 packages to latest compatible versions Updating anyhow v1.0.98 -> v1.0.99 Updating bitflags v2.9.1 -> v2.9.2 Updating cc v1.2.32 -> v1.2.33 Updating clap v4.5.43 -> v4.5.45 Updating clap_builder v4.5.43 -> v4.5.44 Updating clap_complete v4.5.56 -> v4.5.57 Updating clap_derive v4.5.41 -> v4.5.45 Updating proc-macro2 v1.0.95 -> v1.0.101 Updating syn v2.0.104 -> v2.0.106 Updating terminal_size v0.4.2 -> v0.4.3 Updating thiserror v2.0.12 -> v2.0.15 Updating thiserror-impl v2.0.12 -> v2.0.15 ```
…, r=ChrisDenton
std/sys/fd: Relax `READ_LIMIT` on Darwin
Darwin's `read`/`write` syscalls emit `EINVAL` only when `nbyte > INT_MAX`. The case `nbyte == INT_MAX` is valid, so the subtraction (`- 1`) in
```rust
const READ_LIMIT: usize = if cfg!(target_vendor = "apple") {
libc::c_int::MAX as usize - 1 // <- HERE
} else {
libc::ssize_t::MAX as usize
};
```
can be removed.
I tested that the case `nbyte == INT_MAX` is valid on various versions of macOS, including old one like Mac OS X 10.5.
The man page says:
- read() and pread() will fail if the parameter nbyte exceeds INT_MAX (link: https://keith.github.io/xcode-man-pages/read.2.html)
- write() and pwrite() will fail if the parameter nbyte exceeds INT_MAX (link: https://keith.github.io/xcode-man-pages/write.2.html)
Here are links to Darwin's code:
- [macOS 15.5] https://github.com/apple-oss-distributions/xnu/blob/e3723e1f17661b24996789d8afc084c0c3303b26/bsd/kern/sys_generic.c#L307
- [Mac OS X 10.2] https://github.com/apple/darwin-xnu/blob/d738f900846ed2d5f685e18bf85ce63b0176f61a/bsd/kern/sys_generic.c#L220
Related PR: rust-lang#38622.
…f8, r=Mark-Simulacrum Optimize `char::encode_utf8` Save a few instructions in `encode_utf8_raw_unchecked` by performing manual CSE.
…kh726
Add lint against integer to pointer transmutes
# `integer_to_ptr_transmutes`
*warn-by-default*
The `integer_to_ptr_transmutes` lint detects integer to pointer transmutes where the resulting pointers are undefined behavior to dereference.
### Example
```rust
fn foo(a: usize) -> *const u8 {
unsafe {
std::mem::transmute::<usize, *const u8>(a)
}
}
```
```
warning: transmuting an integer to a pointer creates a pointer without provenance
--> a.rs:1:9
|
158 | std::mem::transmute::<usize, *const u8>(a)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this is dangerous because dereferencing the resulting pointer is undefined behavior
= note: exposed provenance semantics can be used to create a pointer based on some previously exposed provenance
= help: if you truly mean to create a pointer without provenance, use `std::ptr::without_provenance_mut`
= help: for more information about transmute, see <https://doc.rust-lang.org/std/mem/fn.transmute.html#transmutation-between-pointers-and-integers>
= help: for more information about exposed provenance, see <https://doc.rust-lang.org/std/ptr/index.html#exposed-provenance>
= note: `#[warn(integer_to_ptr_transmutes)]` on by default
help: use `std::ptr::with_exposed_provenance` instead to use a previously exposed provenance
|
158 - std::mem::transmute::<usize, *const u8>(a)
158 + std::ptr::with_exposed_provenance::<u8>(a)
|
```
### Explanation
Any attempt to use the resulting pointers are undefined behavior as the resulting pointers won't have any provenance.
Alternatively, `std::ptr::with_exposed_provenance` should be used, as they do not carry the provenance requirement or if the wanting to create pointers without provenance `std::ptr::without_provenance_mut` should be used.
See [std::mem::transmute] in the reference for more details.
[std::mem::transmute]: https://doc.rust-lang.org/std/mem/fn.transmute.html
--------
People are getting tripped up on this, see rust-lang#128409 and rust-lang#141220. There are >90 cases like these on [GitHub search](https://github.com/search?q=lang%3Arust+%2Ftransmute%3A%3A%3Cu%5B0-9%5D*.*%2C+%5C*const%2F&type=code).
Fixes rust-lang/rust-clippy#13140
Fixes rust-lang#141220
Fixes rust-lang#145523
`@rustbot` labels +I-lang-nominated +T-lang
cc `@traviscross`
r? compiler
…r=Amanieu Fix `LazyLock` poison panic message Fixes the issue raised in rust-lang#144872 (comment) r? ```@Amanieu```
std/src/lib.rs: mention "search button" instead of "search bar" r? ```@GuillaumeGomez```
fixes 134088, though it is a shame to lose some of this wonderful detail.
Dial down detail of B-tree description fixes rust-lang#134088, though it is a shame to lose some of this wonderful detail. r? `@workingjubilee` EDIT: newest versions keep old detail, but move it down a bit.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is an automated PR to merge library subtree updates from 2025-08-20 (rust-lang/rust@05f5a58) to 2025-08-26 (rust-lang/rust@54c5812), inclusive. This is a clean merge, no conflicts were detected. Do not remove or edit the following annotations:
git-subtree-dir: library
git-subtree-split: b8acf06