Merge subtree update for toolchain nightly-2025-12-03#590
Open
github-actions[bot] wants to merge 10000 commits intomainfrom
Open
Merge subtree update for toolchain nightly-2025-12-03#590github-actions[bot] wants to merge 10000 commits intomainfrom
github-actions[bot] wants to merge 10000 commits intomainfrom
Conversation
…]` on `Copy`, introduce `TrivialClone`
If each of the component types is `TrivialClone`, the closure/tuple itself can be trivially cloned.
…-dead Remove `#[const_trait]` Remove `#[const_trait]` since we now have `const trait`. Update all structured diagnostics that still suggested the attribute. r? ```@rust-lang/project-const-traits```
…risDenton std: use a non-poisoning `RwLock` for the panic hook The code ignored poison errors using `PoisonError` anyway.
Implement IsZero for (). Implement default `IsZero` for all arrays, only returning true if the array is empty (making the existing array impl for `IsZero` elements a specialization). Optimize `IsZero::is_zero` for arrays of zero-sized `IsZero` elements.
…-Simulacrum Constify `ControlFlow` methods without unstable bounds Feature: `min_const_control_flow` Tracking issue: rust-lang#148738 This PR constifies some of the methods on `ControlFlow`.
…rk-Simulacrum Constify `ControlFlow` methods with unstable bounds Feature: `const_control_flow` Tracking issue: rust-lang#148739 This PR constifies the methods on `ControlFlow` with a dependency on rust-lang#143874.
This updates the rust-version file to 8401398.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 8401398 Filtered ref: f9e99a8e85fa360f0e820dc75d46cb4583b4300d Upstream diff: rust-lang/rust@73e6c9e...8401398 This merge was created using https://github.com/rust-lang/josh-sync.
- Add FileTimes implementation. Signed-off-by: Ayush Singh <ayush@beagleboard.org>
…nwind and compiler crates
stop specializing on `Copy` fixes rust-lang#132442 `std` specializes on `Copy` to optimize certain library functions such as `clone_from_slice`. This is unsound, however, as the `Copy` implementation may not be always applicable because of lifetime bounds, which specialization does not take into account; the result being that values are copied even though they are not `Copy`. For instance, this code: ```rust struct SometimesCopy<'a>(&'a Cell<bool>); impl<'a> Clone for SometimesCopy<'a> { fn clone(&self) -> Self { self.0.set(true); Self(self.0) } } impl Copy for SometimesCopy<'static> {} let clone_called = Cell::new(false); // As SometimesCopy<'clone_called> is not 'static, this must run `clone`, // setting the value to `true`. let _ = [SometimesCopy(&clone_called)].clone(); assert!(clone_called.get()); ``` should not panic, but does ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6be7a48cad849d8bd064491616fdb43c)). To solve this, this PR introduces a new `unsafe` trait: `TrivialClone`. This trait may be implemented whenever the `Clone` implementation is equivalent to copying the value (so e.g. `fn clone(&self) -> Self { *self }`). Because of lifetime erasure, there is no way for the `Clone` implementation to observe lifetime bounds, meaning that even if the `TrivialClone` has stricter bounds than the `Clone` implementation, its invariant still holds. Therefore, it is sound to specialize on `TrivialClone`. I've changed all `Copy` specializations in the standard library to specialize on `TrivialClone` instead. Unfortunately, the unsound `#[rustc_unsafe_specialization_marker]` attribute on `Copy` cannot be removed in this PR as `hashbrown` still depends on it. I'll make a PR updating `hashbrown` once this lands. With `Copy` no longer being considered for specialization, this change alone would result in the standard library optimizations not being applied for user types unaware of `TrivialClone`. To avoid this and restore the optimizations in most cases, I have changed the expansion of `#[derive(Clone)]`: Currently, whenever both `Clone` and `Copy` are derived, the `clone` method performs a copy of the value. With this PR, the derive macro also adds a `TrivialClone` implementation to make this case observable using specialization. I anticipate that most users will use `#[derive(Clone, Copy)]` whenever both are applicable, so most users will still profit from the library optimizations. Unfortunately, Hyrum's law applies to this PR: there are some popular crates which rely on the precise specialization behaviour of `core` to implement "specialization at home", e.g. [`libAFL`](https://github.com/AFLplusplus/LibAFL/blob/89cff637025c1652c24e8d97a30a2e3d01f187a4/libafl_bolts/src/tuples.rs#L27-L49). I have no remorse for breaking such horrible code, but perhaps we should open other, better ways to satisfy their needs – for example by dropping the `'static` bound on `TypeId::of`...
Implement IsZero for (), and optimize `IsZero::is_zero` for arrays
These are probably not super useful optimizations, but they make it so that `vec![expr; LARGE_LENGTH]` has better performance for some `expr`s, e.g.
* array of length zero in debug mode
* tuple containing `()` and zero-valued integers in debug and release mode
* array of `()` or other zero-sized `IsZero` type in debug mode
<details> <summary>very rough benchmarks</summary>
```Rust
use std::time::Instant;
use std::sync::atomic::{AtomicUsize, Ordering::Relaxed};
struct NonCopyZst;
static COUNTER: AtomicUsize = AtomicUsize::new(0);
impl Clone for NonCopyZst {
fn clone(&self) -> Self {
COUNTER.fetch_add(1, Relaxed);
Self
}
}
macro_rules! timeit {
($e:expr) => {
let start = Instant::now();
_ = $e;
println!("{:56}: {:?}", stringify!($e), start.elapsed());
};
}
fn main() {
timeit!(vec![[String::from("hello"); 0]; 1_000_000_000]); // gets a lot better in debug mode
timeit!(vec![(0u8, (), 0u16); 1_000_000_000]); // gets a lot better in debug *and* release mode
timeit!(vec![[[(); 37]; 1_000_000_000]; 1_000_000_000]); // gets a lot better in debug mode
timeit!(vec![[NonCopyZst; 0]; 1_000_000_000]); // gets a lot better in debug mode
timeit!(vec![[[1u8; 0]; 1_000_000]; 1_000_000]); // gets a little bit better in debug mode
timeit!(vec![[[(); 37]; 1_000_000]; 1_000_000]); // gets a little bit better in debug mode
timeit!(vec![[[1u128; 0]; 1_000_000]; 1_000_000]); // gets a little bit better in debug mode
// check that we don't regress existing optimizations
timeit!(vec![(0u8, 0u16); 1_000_000_000]); // about the same time
timeit!(vec![0u32; 1_000_000_000]); // about the same time
// check that we still call clone for non-IsZero ZSTs
timeit!(vec![[const { NonCopyZst }; 2]; 1_000]); // about the same time
assert_eq!(COUNTER.load(Relaxed), 1998);
timeit!(vec![NonCopyZst; 10_000]); // about the same time
assert_eq!(COUNTER.load(Relaxed), 1998 + 9_999);
}
```
```rs
$ cargo +nightly run
// ...
vec![[String::from("hello"); 0]; 1_000_000_000] : 11.13999724s
vec![(0u8, (), 0u16); 1_000_000_000] : 5.254646651s
vec![[[(); 37]; 1_000_000_000]; 1_000_000_000] : 2.738062531s
vec![[NonCopyZst; 0]; 1_000_000_000] : 9.483690922s
vec![[[1u8; 0]; 1_000_000]; 1_000_000] : 2.919236ms
vec![[[(); 37]; 1_000_000]; 1_000_000] : 2.927755ms
vec![[[1u128; 0]; 1_000_000]; 1_000_000] : 2.931486ms
vec![(0u8, 0u16); 1_000_000_000] : 19.46µs
vec![0u32; 1_000_000_000] : 9.34µs
vec![[const { NonCopyZst }; 2]; 1_000] : 31.88µs
vec![NonCopyZst; 10_000] : 36.519µs
```
```rs
$ cargo +dev run
// ...
vec![[String::from("hello"); 0]; 1_000_000_000] : 4.12µs
vec![(0u8, (), 0u16); 1_000_000_000] : 16.299µs
vec![[[(); 37]; 1_000_000_000]; 1_000_000_000] : 210ns
vec![[NonCopyZst; 0]; 1_000_000_000] : 210ns
vec![[[1u8; 0]; 1_000_000]; 1_000_000] : 170ns
vec![[[(); 37]; 1_000_000]; 1_000_000] : 110ns
vec![[[1u128; 0]; 1_000_000]; 1_000_000] : 140ns
vec![(0u8, 0u16); 1_000_000_000] : 11.56µs
vec![0u32; 1_000_000_000] : 10.71µs
vec![[const { NonCopyZst }; 2]; 1_000] : 36.08µs
vec![NonCopyZst; 10_000] : 73.21µs
```
(checking release mode to make sure this doesn't regress perf there)
```rs
$ cargo +nightly run --release
// ...
vec![[String::from("hello"); 0]; 1_000_000_000] : 70ns
vec![(0u8, (), 0u16); 1_000_000_000] : 1.269457501s
vec![[[(); 37]; 1_000_000_000]; 1_000_000_000] : 10ns
vec![[NonCopyZst; 0]; 1_000_000_000] : 20ns
vec![[[1u8; 0]; 1_000_000]; 1_000_000] : 10ns
vec![[[(); 37]; 1_000_000]; 1_000_000] : 20ns
vec![[[1u128; 0]; 1_000_000]; 1_000_000] : 20ns
vec![(0u8, 0u16); 1_000_000_000] : 20ns
vec![0u32; 1_000_000_000] : 20ns
vec![[const { NonCopyZst }; 2]; 1_000] : 2.66µs
vec![NonCopyZst; 10_000] : 13.39µs
```
```rs
$ cargo +dev run --release
vec![[String::from("hello"); 0]; 1_000_000_000] : 90ns
vec![(0u8, (), 0u16); 1_000_000_000] : 30ns
vec![[[(); 37]; 1_000_000_000]; 1_000_000_000] : 20ns
vec![[NonCopyZst; 0]; 1_000_000_000] : 30ns
vec![[[1u8; 0]; 1_000_000]; 1_000_000] : 20ns
vec![[[(); 37]; 1_000_000]; 1_000_000] : 20ns
vec![[[1u128; 0]; 1_000_000]; 1_000_000] : 20ns
vec![(0u8, 0u16); 1_000_000_000] : 30ns
vec![0u32; 1_000_000_000] : 20ns
vec![[const { NonCopyZst }; 2]; 1_000] : 3.52µs
vec![NonCopyZst; 10_000] : 17.13µs
```
</details>
The specific expression I ran into a perf issue that this PR addresses is `vec![[(); LARGE]; LARGE]`, as I was trying to demonstrate `Vec::into_flattened` panicking on length overflow in the playground, but got a timeout error instead since `vec![[(); LARGE]; LARGE]` took so long to run in debug mode (it runs fine on the playground in release mode)
…nteger, r=urgau
Add new `function_casts_as_integer` lint
The `function_casts_as_integer` lint detects cases where users cast a function pointer into an integer.
*warn-by-default*
### Example
```rust
fn foo() {}
let x = foo as usize;
```
```
warning: casting a function into an integer implicitly
--> $DIR/function_casts_as_integer.rs:9:17
|
LL | let x = foo as usize;
| ^^^^^^^^
|
help: add `fn() as usize`
|
LL | let x = foo as fn() as usize;
| +++++++
```
### Explanation
You should never cast a function directly into an integer but go through a cast as `fn` first to make it obvious what's going on. It also allows to prevent confusion with (associated) constants.
Related to rust-lang#81686 and https://stackoverflow.com/questions/68701177/whats-the-meaning-of-casting-a-rust-enum-variant-to-a-numeric-data-type
r? ````@urgau````
Rename `*exact_{div,shr,shl}` to `*{div,shr,shl}_exact`
Related to rust-lang#144336 and rust-lang#139911, see rust-lang#139911 (comment). I haven't touched the `exact_div`, `exact_udiv` and `exact_sdiv` intrinsics. Let me know if I should.
std: support `RwLock` and thread parking on TEEOS Since TEEOS supports pthread mutexes and condvars, it can share the pthread-based thread parking implementation and thus also the queue-based `RwLock` implementation used on other platforms. CC ``@petrochenkov`` ``@Sword-Destiny``
Fix a typo in the documentation for the strict_shr function fix: rust-lang#148761
…lize, r=Amanieu Stabilize `unchecked_neg` and `unchecked_shifts` Features: `unchecked_neg`, `unchecked_shifts` Tracking issue: rust-lang#85122 r? `@Amanieu`
Show backtrace on allocation failures when possible And if an allocation while printing the backtrace fails, don't try to print another backtrace as that will never succeed. Split out of rust-lang#147725 to allow landing this independently of a decision whether or not to remove `-Zoom=panic`.
…crum Allow the global allocator to use thread-local storage and std::thread::current() Fixes rust-lang#115209. Currently the thread-local storage implementation uses the `Global` allocator if it needs to allocate memory in some places. This effectively means the global allocator can not use thread-local variables. This is a shame as an allocator is precisely one of the locations where you'd *really* want to use thread-locals. We also see that this lead to hacks such as rust-lang#116402, where we detect re-entrance and abort. So I've made the places where I could find allocation happening in the TLS implementation use the `System` allocator instead. I also applied this change to the storage allocated for a `Thread` handle so that it may be used care-free in the global allocator as well, for e.g. registering it to a central place or parking primitives. r? `@joboet`
float::minimum/maximum: say which exact IEEE operation this corresponds to There's both `minimum` and `minimumNumber`, so this seems worth clarifying. Also use code font for these names to make it more clear that they are technical terms.
…ent, r=chenyukang Remove outdated comment The comment was added in rust-lang#136897 , but wasn't removed when the feature gate was stabilized (again). Also, `it's` -> `its` :)
Rollup of 5 pull requests Successful merges: - rust-lang#147362 (Avoid suggesting constrain the associated type with unknown type) - rust-lang#149395 (float::minimum/maximum: say which exact IEEE operation this corresponds to) - rust-lang#149396 (Remove outdated comment) - rust-lang#149421 (Add a regression test for issue 129865) - rust-lang#149424 (Update books) r? `@ghost` `@rustbot` modify labels: rollup
- Implement remove_dir and remove_file. - Tested on qemu ovmf. Signed-off-by: Ayush Singh <ayush@beagleboard.org>
std: split up the `thread` module Almost all functionality in `std::thread` is currently implemented in `thread/mod.rs`, resulting in a *huge* file with more than 2000 lines and multiple, interoperating `unsafe` sections. This PR splits the file up into multiple different private modules, each implementing mostly independent parts of the functionality. The only remaining `unsafe` interplay is that of the `lifecycle` and `scope` modules, the `spawn_scoped` implementation relies on the live thread count being updated correctly by the `lifecycle` module. This PR contains no functional changes and only moves code around for the most part, with a few notable exceptions: * `with_current_name` is moved to the already existing `current` module and now uses the `name` method instead of calculating the name from private fields. The old code was just a reimplementation of that method anyway. * The private `JoinInner` type used to implement both join handles now has some more methods (`is_finished`, `thread` and the `AsInner`/`IntoInner` implementations) to avoid having to expose private fields and their invariants. * The private `spawn_unchecked_` (note the underscore) method of `Builder` is now a freestanding function in `lifecycle`. The rest of the changes are just visibility annotations. I realise this PR ended up quite large – let me know if there is anyway I can aid the review process. Edit: I've simplified the diff by adding an intermediate commit that creates all the new files by duplicating `mod.rs`. The actual changes in the second commit thus appear to delete the non-relevant parts from the respective file.
Clarify edge cases for Barrier::new ... since n-1 is undefined when the usize n is 0.
float::min/max: reference NaN bit pattern rules Also, the "in particular" transition to the signed zero handling was odd, so I rearranged things a bit: first a self-contained description of the semantics, then an explanation of which operations in other standards/libraries this most closely corresponds to. r? `@tgross35`
Added feature gate, documentation and tests also.
ThreadId generation fallback path: avoid spurious yields Fixes rust-lang/miri#4737 Alternative to rust-lang#149476 Cc `@orlp` `@joboet`
Implement `clamp_magnitude` method for primitive floats & signed integers Tracking issue rust-lang#148519 ACP rust-lang/libs-team#686
stabilize maybe_uninit_slice Tracking issue: rust-lang#63569 Closes: rust-lang#63569 FCP completed: rust-lang#63569 (comment) Removes: ```rs pub const fn slice_as_ptr(this: &[MaybeUninit<T>]) -> *const T; pub const fn slice_as_mut_ptr(this: &mut [MaybeUninit<T>]) -> *mut T; ```
…nieu [std][BTree] Fix behavior of `::append` to match documentation, `::insert`, and `::extend` Resolves rust-lang#145614
…metal, r=davidtwco Fix armv4t- and armv5te- bare metal targets These two targets currently force on the LLVM feature `+atomics-32`. LLVM doesn't appear to actually be able to emit 32-bit load/store atomics for these targets despite this feature, and emits calls to a shim function called `__sync_lock_test_and_set_4`, which nothing in the Rust standard library supplies. See [#t-compiler/arm > __sync_lock_test_and_set_4 on Armv5TE](https://rust-lang.zulipchat.com/#narrow/channel/242906-t-compiler.2Farm/topic/__sync_lock_test_and_set_4.20on.20Armv5TE/with/553724827) for more details. Experimenting with clang and gcc (as logged in that zulip thread) shows that C code cannot do atomic load/stores on that architecture either (at least, not without a library call inserted). So, the safest thing to do is probably turn off `+atomics-32` for these two Tier 3 targets. I asked `@Lokathor` and he said he didn't even use atomics on the `armv4t-none-eabi`/`thumbv4t-none-eabi` target he maintains. I was unable to reach `@QuinnPainter` for comment for `armv5te-none-eabi`/`thumbv5te-none-eabi`. The second commit renames the base target spec `spec::base::thumb` to `spec::base::arm_none` and changes `armv4t-none-eabi`/`thumbv4t-none-eabi` and `armv5te-none-eabi`/`thumbv5te-none-eabi` to use it. This harmonises the frame-pointer and linker options across the bare-metal Arm EABI and EABIHF targets. You could make an argument for harmonising `armv7a-none-*`, `armv7r-none*` and `armv8r-none-*` as well, but that can be another PR.
…ubilee In `BTreeMap::eq`, do not compare the elements if the sizes are different. Reverts rust-lang#147101 in library/alloc/src/btree/ rust-lang#147101 replaced some instances of code like `a.len() == b.len() && a.iter().eq(&b)` with just `a.iter().eq(&b)`, but the optimization that PR introduced only applies for `TrustedLen` iterators, and `BTreeMap`'s itertors are not `TrustedLen`, so this theoretically regressed perf for comparing large `BTreeMap`/`BTreeSet`s with unequal lengths but equal prefixes, (and also made it so that comparing two different-length `BTreeMap`/`BTreeSet`s with elements whose `PartialEq` impls that can panic now can panic, though this is not a "promised" behaviour either way (cc rust-lang#149122)) Given that `TrustedLen` is an unsafe trait, I opted to not implement it for `BTreeMap`'s iterators, and instead just revert the change. If someone else wants to audit `BTreeMap`'s iterators to make sure they always return the right number of items (even in the face of incorrect user `Ord` impls) and then implement `TrustedLen` for them so that the optimization works for them, then this can be closed in favor of that (or if the perf regression is deemed too theoretical, this can be closed outright). Example of theoretical perf regression: https://play.rust-lang.org/?version=beta&mode=release&edition=2024&gist=a37e3d61e6bf02669b251315c9a44fe2 (very rough estimates, using `Instant::elapsed`). In release mode on stable the comparison takes ~23.68µs. In release mode on beta/nightly the comparison takes ~48.351057ms.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
19 participants
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-10-09 (rust-lang/rust@b6f0945) to 2025-12-03 (rust-lang/rust@646a3f8) (inclusive) into main.
git mergeresulted in conflicts, which require manual resolution. Files were commited with merge conflict markers. Do not remove or edit the following annotations:git-subtree-dir: library
git-subtree-split: 88f8387