Merge subtree update for toolchain nightly-2025-08-20 #476
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}
So there will no longer be the need to close and reopen sync PRs in order for CI to run.
Adds the equivalent `nonpoison` types to the `poison::mutex` module. These types and implementations are gated under the `nonpoison_mutex` feature gate. Also blesses the ui tests that now have a name conflicts (because these types no longer have unique names). The full path distinguishes the different types. Co-authored-by: Aandreba <[email protected]> Co-authored-by: Trevor Gross <[email protected]>
This commit simply helps discern the actual changes needed to test both poison and nonpoison locks.
Adds tests for the `nonpoison::Mutex` variant by using a macro to duplicate the existing `poison` tests. Note that all of the tests here are adapted from the existing `poison` tests.
…oss35 Implementation: `#[feature(sync_nonpoison)]`, `#[feature(nonpoison_mutex)]` Continuation of rust-lang#134663 Tracking Issue: rust-lang#134645 This PR implements a new `sync/nonpoison` module, as well as the `nonpoison` variant of the `Mutex` lock. There are 2 main changes here, the first is the new `nonpoison::mutex` module, and the second is the `mutex` integration tests. For the `nonpoison::mutex` module, I did my best to align it with the current state of the `poison::mutex` module. This means that several unstable features (`mapped_lock_guards`, `lock_value_accessors`, and `mutex_data_ptr`) are also in the new `nonpoison::mutex` module, under their respective feature gates. Everything else in that file is under the correct feature gate (`#[unstable(feature = "nonpoison_mutex", issue = "134645")]`). Everything in the `nonpoison::mutex` file is essentially identical in spirit, as we are simply removing the error case from the original `poison::mutex`. The second big change is in the integration tests. I created a macro called that allows us to duplicate tests that are "generic" over the different mutex types, in that the poison mutex is always `unwrap`ped. ~~I think that there is an argument against doing this, as it can make the tests a bit harder to understand (and language server capabilities are weaker within macros), but I think the benefit of code deduplication here is worth it. Note that it is definitely possible to generalize this (with a few tweaks) to testing the other `nonpoison` locks when they eventually get implemented, but I'll leave that for a later discussion.~~
…ason, r=tgross35 Document why `Range*<&T> as RangeBounds<T>` impls are not `T: ?Sized`, and give an alternative. `Range*<&T> as RangeBounds<T>` impls have been tried to be relaxed to `T: ?Sized` at least twice: * rust-lang#61584 * rust-lang#64327 I also was just about to make another PR to do it again until I `./x.py test library/alloc` and rediscovered the type inference regression, then searched around and found the previous PRs. Hence this PR instead so hopefully that doesn't keep happening 😛. These impls cannot be relaxed for two reasons: 1. Type inference regressions: See ``@SimonSapin's`` explanation from a previous PR: rust-lang#61584 (comment) 2. It's a breaking change: `impl RangeBounds<MyUnsizedType> for std::ops::Range<&MyUnsizedType>` is allowed after the coherence rebalance ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=f704a6fe53bfc33e55b2fc246d895ec2)), and relaxing these impls would conflict with that downstream impl. This PR adds doc-comments explaining that not having `T: ?Sized` is intentional[^1], and gives an explicit alternative: `(Bound<&T>, Bound<&T>)`. Technically, the impls for the unstable new `std::range` types could be relaxed, as they are still unstable so the change would not be breaking, but having them be different in this regard seems worse (and the non-iterable `RangeTo/RangeToInclusive` range types are shared between the "new" and "old" so cannot be changed anyway), and then the type inference regression would pop up in whatever edition the new range types stabilize in. The "see \<link\> for discussion of those issues" is intentionally left as a non-doc comment just for whoever may try to relax these impls again in the future, but if it is preferred to have the link in the docs I can add that. Closes rust-lang#107196 (as wontfix) CC rust-lang#64027 [^1]: "intentional" is maybe a bit of strong wording, should it instead say something like "was stabilized without it and it would be breaking to change it now"?
… r=ChrisDenton thread name in stack overflow message Fixes rust-lang#144481, which is caused by the thread name not being initialised yet when setting up the stack overflow information. Unfortunately, the stack overflow UI test did not test for the correct thread name being present, and testing this separately didn't occur to me when writing rust-lang#140628. This PR contains the smallest possible fix I could think of: passing the thread name explicitly to the platform thread creation function. In the future I'd very much like to explore some possibilities around merging the thread packet and thread handle into one structure and using that in the platform code instead – but that's best left for another PR. This PR also amends the stack overflow test to check for thread names, so we don't run into this again. ``@rustbot`` label +beta-nominated
Benchmark results with LLVM 21 on LA664: ``` OLD: test bench_is_contained_in ... bench: 43.63 ns/iter (+/- 0.04) NEW: test bench_is_contained_in ... bench: 12.81 ns/iter (+/- 0.01) ```
Fix typo in `DropGuard` doc Follows-up rust-lang#144236 (I happened to see the typo yesterday but didn’t think it should delay the PR’s merge so I kept quiet, sorryyyyy).
Rather than setting an environment variable in the workflow job based on
whether or not the environment is non-MinGW Windows, we can just check
this in the ci script.
This was originally added in b0f19660f0 ("Add tests for UNC paths on
windows builds") and its followup commits.
Faster equality compare Add tests Add missing files for tests
LoongArch64 LSX fast-path for `str.contains(&str)` Benchmark results with LLVM 21 on LA664: ``` OLD: test bench_is_contained_in ... bench: 43.63 ns/iter (+/- 0.04) NEW: test bench_is_contained_in ... bench: 12.81 ns/iter (+/- 0.01) ```
Fix Ord, Eq and Hash implementation of panic::Location Fixes rust-lang#144486. Now properly compares/hashes the filename rather than the pointer to the string.
Rollup of 8 pull requests Successful merges: - rust-lang#144034 (tests: Test line number in debuginfo for diverging function calls) - rust-lang#144510 (Fix Ord, Eq and Hash implementation of panic::Location) - rust-lang#144583 (Enable T-compiler backport nomination) - rust-lang#144586 (Update wasi-sdk to 27.0 in CI) - rust-lang#144605 (Resolve: cachify `ExternPreludeEntry.binding` through a `Cell`) - rust-lang#144632 (Update some tests for LLVM 21) - rust-lang#144639 (Update rustc-perf submodule) - rust-lang#144640 (Add support for the m68k architecture in 'object_architecture') r? `@ghost` `@rustbot` modify labels: rollup
Since it's cfg'd instead of type-aliased
Replace the current system with something that is more structured and will also catch unknown directives.
Use `tee` rather than printing to both stdout and stderr.
Introduce a new directive `ci: test-libm` to ensure tests run.
Currently, a failure in `ci-util.py` does not cause the job to fail
because the pipe eats the failure status . Set pipefail to fix this.
Fixes: ff2cc0e38e3e ("ci: Don't print output twice in `ci-util`")
Currently, attributes for `no-panic` are gated behind both the `test` config and `assert_no_panic`, because `no-panic` is a dev dependency (so only available with test configuration). However, we only emit `assert_no_panic` when the test config is also set anyway, so there isn't any need to gate on both. Replace gates on `all(test, assert_no_panic)` with only `assert_no_panic`. This is simpler, and also has the benefit that attempting to check for panics without `--test` errors.
This updates the rust-version file to 32e7a4b.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 32e7a4b Filtered ref: 56d8aa13f54944edb711f3bdd7013b082dbaa65b This merge was created using https://github.com/rust-lang/josh-sync.
library: Migrate from `cfg_if` to `cfg_select`
Migrate the standard library from using the external `cfg_if` crate to using the now-built-in `cfg_select` macro.
This does not yet eliminate the dependency from `library/std/Cargo.toml`, because while the standard library itself no longer uses `cfg_if`, it also incorporates the `backtrace` crate, which does.
Migration assisted by the following vim command (after selecting the full `cfg_if!` invocation):
```
'<,'>s/\(cfg_if::\)\?cfg_if/cfg_select/ | '<,'>s/^\( *\)} else {/\1}\r\1_ => {/c | '<,'>s/^\( *\)} else if #\[cfg(\(.*\))\] /\1}\r\1\2 => /e | '<,'>s/if #\[cfg(\(.*\))\] {/\1 => {/e
```
This is imperfect, but substantially accelerated the process. This prompts for confirmation on the `} else {` since that can also appear inside one of the arms. This also requires manual intervention to handle any multi-line conditions.
…h, r=Amanieu
`impl PartialEq<{str,String}> for {Path,PathBuf}`
This is a revival of rust-lang#105877
Comparison of paths and strings is expected to be possible and needed e.g. in tests. This change adds the impls os `PartialEq` between strings and paths, both owned and unsized, in both directions.
ACP: rust-lang/libs-team#151
Stabilize `ip_from` Tracking issue: rust-lang#131360 Stabilizes and const-stabilizes the following APIs: ```rust // core::net impl Ipv4Addr { pub const fn from_octets(octets: [u8; 4]) -> Ipv4Addr; } impl Ipv6Addr { pub const fn from_octets(octets: [u8; 16]) -> Ipv6Addr; pub const fn from_segments(segments: [u16; 8]) -> Ipv6Addr; } ``` Closes rust-lang#131360 ```@rustbot``` label +needs-fcp
…spose, r=ibraheemdev Trivial improve doc for transpose When I saw old doc, I felt a little confused. Seems it would be clearer this way.
…_sleep_tests_on_sgx, r=Mark-Simulacrum [RTE-513] Ignore sleep_until test on SGX rust-lang#141829 added a test for `sleep_until`: it checks whether its specification holds: > Puts the current thread to sleep until the specified deadline has passed. but in SGX there's no secure time source. There's only the ability to request the `insecure_time` from outside of the enclave through a [usercall](https://github.com/fortanix/rust-sgx/blob/master/intel-sgx/fortanix-sgx-abi/src/lib.rs#L590-L592) and the ability to [wait](https://github.com/rust-lang/rust/blob/master/library/std/src/sys/pal/sgx/abi/usercalls/mod.rs#L173-L179) for a certain event or timeout. But both are under the control of an attacker; users should not depend on the accuracy nor correctness of this time. We try to even enforce this by adding a +/-10% time interval to wait usercalls. The current `thread::sleep_until` implementation uses this `wait` usercall. When a negative randomization interval is added to the timeout passed in `wait`, the test fails. As users should not rely on the correctness of any time inside the enclave, it should be considered an incorrect test on SGX. This PR ignores this test.
…=petrochenkov Remove the `From` derive macro from prelude The new `#[derive(From)]` functionality (implemented in rust-lang#144922) caused name resolution ambiguity issues (rust-lang#145524). The reproducer looks e.g. like this: ```rust mod foo { pub use derive_more::From; } use foo::*; #[derive(From)] // ERROR: `From` is ambiguous struct S(u32); ``` It's pretty unfortunate that it works like this, but I guess that there's not much to be done here, and we'll have to wait for the next edition to put the `From` macro into the prelude. That will probably require rust-lang#139493 to land. I created a new module in core (and re-exported it in std) called `from`, where I re-exported the `From` macro. I *think* that since this is a new module, it should not have the same backwards incompatibility issue. Happy to hear suggestions about the naming - maybe it would make sense as `core::macros::from::From`? But we already had a precedent in the `core::assert_matches` module, so I just followed suit. Fixes: rust-lang#145524 r? ``@petrochenkov``
…ofollow, r=ibraheemdev implement std::fs::set_permissions_nofollow on unix implementation of rust-lang#141607
…oss35
fmt of non-decimal radix untangled
Have the implementation match its decimal counterpart.
* Digit table instead of conversion functions
* Correct buffer size per radix
* Elimination of dead code for negative
* No trait abstraction for integers
#### Original Performance
```
fmt::write_10ints_bin 393.03ns/iter +/- 1.41
fmt::write_10ints_hex 316.84ns/iter +/- 1.49
fmt::write_10ints_oct 327.16ns/iter +/- 0.46
```
#### Patched Performance
```
fmt::write_10ints_bin 392.31ns/iter +/- 3.05
fmt::write_10ints_hex 302.41ns/iter +/- 5.48
fmt::write_10ints_oct 322.01ns/iter +/- 3.82
```
r? tgross35
Correct some grammar in integer documentation Update "between" to "among" (more than two items), connect the "which" dependent clause to the independent part, and remove the redundant "here".
…=Kobzol run spellcheck as a tidy extra check in ci This is probably how it should've been done from the start. r? ``@Kobzol``
rustc_target: Add the `32s` target feature for LoongArch LLVM: llvm/llvm-project#139695
…emdev dec2flt: Provide more valid inputs examples I was just looking at the specifics of how the parsing is handled here and I wasn't sure if the examples were incomplete or the grammar below was misleading. The grammar was correct so I figured I'd add these examples to clarify.
…heemdev Hide docs for `core::unicode` This module is perma-unstable and shouldn't show up in the public docs. If people want to see the docs for it, they can still run `RUSTDOCFLAGS=--document-hidden-items ./x doc library/core`.
…string_new, r=ibraheemdev Stabilize `const_pathbuf_osstring_new` feature This closes [tracking issue](rust-lang#141520) and stabilises `{OsString, PathBuf}::new` in const
…riplett
Rust build fails on OpenBSD after using file_lock feature
PR 130999 added the file_lock feature, but doesn't included OpenBSD in the supported targets (Tier 3 platform), leading to a compilation error ("try_lock() not supported").
Cc `@cberner`
Related to rust-lang#130999
Rollup of 15 pull requests Successful merges: - rust-lang#145338 (actually provide the correct args to coroutine witnesses) - rust-lang#145429 (Couple of codegen_fn_attrs improvements) - rust-lang#145452 (Do not strip binaries in bootstrap everytime if they are unchanged) - rust-lang#145464 (Stabilize `const_pathbuf_osstring_new` feature) - rust-lang#145474 (Properly recover from parenthesized use-bounds (precise capturing lists) plus small cleanups) - rust-lang#145486 (Fix `unicode_data.rs` mention message) - rust-lang#145490 (Trace some basic I/O operations in bootstrap) - rust-lang#145493 (remove `should_render` in `PrintAttribute` derive) - rust-lang#145500 (Port must_use to the new target checking) - rust-lang#145505 (Simplify span caches) - rust-lang#145510 (Visit and print async_fut local for async drop.) - rust-lang#145511 (Rust build fails on OpenBSD after using file_lock feature) - rust-lang#145532 (resolve: debug for block module) - rust-lang#145533 (Reorder `lto` options from most to least optimizing) - rust-lang#145537 (Do not consider a `T: !Sized` candidate to satisfy a `T: !MetaSized` obligation.) r? `@ghost` `@rustbot` modify labels: rollup
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
tautschnig
approved these changes
Aug 21, 2025
thanhnguyen-aws
approved these changes
Aug 21, 2025
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-19 (rust-lang/rust@9eb4a26) to 2025-08-20 (rust-lang/rust@05f5a58), 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: 71d8d81