std-detect: improve detect macro docs
Specifically, document that the detect macros expand to `true` when the feature is statically enabled.
Now that we have a bunch of these macros, perhaps we should streamline further how they are documented?
r? ``@Amanieu``
Add alignment parameter to `simd_masked_{load,store}`
This PR adds an alignment parameter in `simd_masked_load` and `simd_masked_store`, in the form of a const-generic enum `core::intrinsics::simd::SimdAlign`. This represents the alignment of the `ptr` argument in these intrinsics as follows
- `SimdAlign::Unaligned` - `ptr` is unaligned/1-byte aligned
- `SimdAlign::Element` - `ptr` is aligned to the element type of the SIMD vector (default behavior in the old signature)
- `SimdAlign::Vector` - `ptr` is aligned to the SIMD vector type
The main motive for this is stdarch - most vector loads are either fully aligned (to the vector size) or unaligned (byte-aligned), so the previous signature doesn't cut it.
Now, stdarch will mostly use `SimdAlign::Unaligned` and `SimdAlign::Vector`, whereas portable-simd will use `SimdAlign::Element`.
- [x] `cg_llvm`
- [x] `cg_clif`
- [x] `miri`/`const_eval`
## Alternatives
Using a const-generic/"const" `u32` parameter as alignment (and we error during codegen if this argument is not a power of two). This, although more flexible than this, has a few drawbacks
- If we use an const-generic argument, then portable-simd somehow needs to pass `align_of::<T>()` as the alignment, which isn't possible without GCE
- "const" function parameters are just an ugly hack, and a pain to deal with in non-LLVM backends
We can remedy the problem with the const-generic `u32` parameter by adding a special rule for the element alignment case (e.g. `0` can mean "use the alignment of the element type), but I feel like this is not as expressive as the enum approach, although I am open to suggestions
cc `@workingjubilee` `@RalfJung` `@BoxyUwU`
library: std: sys: net: uefi: tcp: Implement write_vectored
- A working vectored write implementation for TCP4.
- Also introduces a small helper UefiBox intended to be used with heap allocated UEFI DSTs.
- Tested on OVMF
cc ```@nicholasbishop```
Stabilize `fmt::from_fn`
Resolvesrust-lang/rust#146705, pending its FCP.
As discussed in that tracking issue and rust-lang/rust#117729, this splits `fmt::from_fn` out from the `debug_closure_helpers` feature.
Fix documentation for std::panic::update_hook
The equivalent code given in the documentation of `std::panic::update_hook`[^1] does not compile:
* `set_hook` expects a boxed function
* Missing closing delimiter for the closure
[^1]: rust-lang/rust#92649
This PR reverts RUST-147622 for several reasons:
1. The RUST-147622 PR would format the generated core library code using
an arbitrary `rustfmt` picked up from `PATH`, which will cause
hard-to-debug failures when the `rustfmt` used to format the
generated unicode data code versus the `rustfmt` used to format the
in-tree library code.
2. Previously, the `unicode-table-generator` tests were not run under CI
as part of `coretests`, and since for `x86_64-gnu-aux` job we run
library `coretests` with `miri`, the generated tests unfortunately
caused an unacceptably large Merge CI time regression from ~2 hours
to ~3.5 hours, making it the slowest Merge CI job (and thus the new
bottleneck).
3. This PR also has an unintended effect of causing a diagnostic
regression (RUST-148387), though that's mostly an edge case not
properly handled by `rustc` diagnostics.
Given that these are three distinct causes with non-trivial fixes, I'm
proposing to revert this PR to return us to baseline. This is not
prejudice against relanding the changes with these issues addressed, but
to alleviate time pressure to address these non-trivial issues.
Make explicit that `TypeId`'s layout and size are unstable
Or worded differently, explicitly remark non-stable-guarantee of `TypeId` layout and size.
This PR makes no *additional* guarantees or non-guarantees, it only emphasizes that `TypeId`'s size and layout are unstable like any other `#[repr(Rust)]` types.
This was discussed during [#t-compiler/meetings > [weekly] 2025-10-30 @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202025-10-30/near/547949347), where the compiler team discussed a request https://github.com/rust-lang/rust/pull/148265 to have the standard library (and language) commit to `TypeId` guaranteeing a size upper bound of 16 bytes. In the meeting, the consensus was:
- We were sympathetic to the use case discussed in the request PR, however we feel like this stability guarantee is premature, given that there are unresolved questions surrounding the intended purpose of `TypeId`, and concerns surrounding its collision-resistance properties https://github.com/rust-lang/rust/issues/10389 and https://github.com/rust-lang/rust/issues/129014. We would prefer not making any of such guarantee until the collision-resistance concerns are resolved.
- Committing to a stability guarantee on the size upper bound now would close the door to making `TypeId` larger (even if unlikely for perf reasons).
Given that we have previously broken people who asserted the size of `TypeId` is 8 bytes, it was also discussed in the meeting that we should *explicitly* note that the size and layout of `TypeId` is not a stable guarantee, and is subject to changes between Rust releases, and thus cannot be relied upon -- if breakage in people's code is due to that assumption, it will be considered a won't-fix.
- So even if `#[repr(Rust)]` types have unstable size and layout, this PR makes it explicit for `TypeId` since this type can feel "special" and users can be lead into thinking its size and layout is something they can rely upon.
r? `@scottmcm` (or libs/libs-api/lang)
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#146573 (Constify Range functions)
- rust-lang/rust#146699 (Add `is_ascii` function optimized for LoongArch64 for [u8])
- rust-lang/rust#148026 (std: don't leak the thread closure if destroying the thread attributes fails)
- rust-lang/rust#148135 (Ignore unix socket related tests for VxWorks)
- rust-lang/rust#148211 (clippy fixes and code simplification)
- rust-lang/rust#148395 (Generalize branch references)
- rust-lang/rust#148405 (Fix suggestion when there were a colon already in generics)
r? `@ghost`
`@rustbot` modify labels: rollup
Generalize branch references
It should be safe to merge this before the rename, and I'd like to do that, so we can test if beta/stable PRs work.
r? ``@marcoieni``
Ignore unix socket related tests for VxWorks
Unix Sockets are not implemented in VxWorks, and therefore, ignore testcases related to UnixDatagram, UnixListener and UnixStream.
std: don't leak the thread closure if destroying the thread attributes fails
The comment about double-free is wrong – we can safely drop both the thread attributes and the thread closure. Here, I've used `DropGuard` for the attributes and moved the `Box::into_raw` to just before the `pthread_create`.
- A working vectored write implementation for TCP4.
- Also introduces a small helper UefiBox intended to be used with heap
allocated UEFI DSTs.
- Tested on OVMF
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#135602 (Tweak output of missing lifetime on associated type)
- rust-lang/rust#139751 (Implement pin-project in pattern matching for `&pin mut|const T`)
- rust-lang/rust#142682 (Update bundled musl to 1.2.5)
- rust-lang/rust#148171 (Simplify code to generate line numbers in highlight)
- rust-lang/rust#148263 (Unpin `libc` and `rustix` in `compiler` and `rustbook`)
- rust-lang/rust#148301 ([rustdoc search] Include extern crates when filtering on `import`)
- rust-lang/rust#148330 (Don't require dlltool with the dummy backend on MinGW)
- rust-lang/rust#148338 (cleanup: upstream dropped amx-transpose functionality)
- rust-lang/rust#148340 (Clippy subtree update)
- rust-lang/rust#148343 (`nonpoison::Condvar` should take `MutexGuard` by reference)
r? `@ghost`
`@rustbot` modify labels: rollup
`nonpoison::Condvar` should take `MutexGuard` by reference
Feature: `#![feature(nonpoison_condvar)]`
Tracking Issue: https://github.com/rust-lang/rust/issues/134645
Specific comment: https://github.com/rust-lang/rust/issues/134645#issuecomment-3458525913
Changes the `nonpoison::Condvar` API to take `MutexGuard` by reference instead of ownership.
I'm actually not entirely sure why the current poison variant of `Condvar` takes by ownership, is it just legacy reasons?
Additionally, the `nonpoison_and_poison_unwrap_test` macro doesn't really make sense anymore now that the APIs are completely different, so this reverts that change from a few months ago.
r? ````@Amanieu````
cleanup: upstream dropped amx-transpose functionality
See also LLVM change 5322fb626820. Looks like this was just removed entirely.
It seems a little bad to just drop it, but I don't see an easy way to conditionalize
this and if it's really just Gone and we marked it as unstable (which it looks like
we did?) I guess we should just dump it.
````@rustbot```` label llvm-main
Since non-poisoning `Condvar` take non-poisoing `Mutex`es when
`wait`ing, we do not need to take by ownership since a poison error
cannot occur while we wait.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Setup for writing different tests for the `nonpoison::Condvar` since it
will have a different API.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Enable file locking support in illumos
https://github.com/rust-lang/rust/pull/132977 introduced an allow-list of targets supporting file locking, but forgot to add illumos to it (which introduced support for it in ~2015). `File::lock` and friends are now stable, and the ecosystem is slowly replacing custom libc calls with the standard library. Crucially, in 1.91 both Cargo and bootstrap switched to `File::lock`, both breaking build directory locking.
This PR enables file locking on illumos. Fixes https://github.com/rust-lang/rust/issues/146312.
Use fstatat() in DirEntry::metadata on Apple platforms
Apple supports `fstatat` on macOS >=10.10 ([source](https://gitlab.gnome.org/GNOME/glib/-/issues/2203)), and according to [Platform Support](https://doc.rust-lang.org/beta/rustc/platform-support.html) the oldest supported version is 10.12.
Google says iOS >=10 supports `fstatat` but doesn't provide a source. [*-apple-ios](https://doc.rust-lang.org/beta/rustc/platform-support/apple-ios.html#os-version) says the minimum supported iOS version is 10.0.
Unsure about tvOS, watchOS and visionOS, hoping CI can confirm this.
I am testing with [fastdu](https://github.com/jesseschalken/fastdu) which is effectively a stress test for `DirEntry::metadata`. In one test this provides a **1.13x** speedup.
```
$ hyperfine --warmup 1 'target/release/fastdu testdir' 'fastdu testdir'
Benchmark 1: target/release/fastdu testdir
Time (mean ± σ): 154.6 ms ± 17.4 ms [User: 31.7 ms, System: 187.6 ms]
Range (min … max): 148.4 ms … 225.5 ms 19 runs
Benchmark 2: fastdu testdir
Time (mean ± σ): 175.3 ms ± 15.8 ms [User: 50.0 ms, System: 196.2 ms]
Range (min … max): 165.4 ms … 211.7 ms 17 runs
Summary
target/release/fastdu testdir ran
1.13 ± 0.16 times faster than fastdu testdir
```
You can also reproduce a speedup with a program like this (providing a directory with many entries):
```rust
fn main() {
let args: Vec<_> = std::env::args_os().collect();
let dir: PathBuf = args[1].clone().into();
for entry in dir.read_dir().as_mut().unwrap() {
let entry = entry.as_ref().unwrap();
let metadata = entry.metadata();
let metadata = metadata.as_ref().unwrap();
println!("{} {}", metadata.len(), entry.file_name().display());
}
}
```
```
$ hyperfine './target/release/main testdir' './main testdir'
Benchmark 1: ./target/release/main testdir
Time (mean ± σ): 148.3 ms ± 5.2 ms [User: 23.1 ms, System: 122.9 ms]
Range (min … max): 145.2 ms … 167.2 ms 19 runs
Benchmark 2: ./main testdir
Time (mean ± σ): 164.4 ms ± 9.5 ms [User: 32.6 ms, System: 128.8 ms]
Range (min … max): 158.5 ms … 199.5 ms 17 runs
Summary
./target/release/main testdir ran
1.11 ± 0.07 times faster than ./main testdir
```
`unicode_data` refactors
Minor refactors to `unicode_data` that occured to me while trying to reduce the size of the tables. Splitting into a separate PR. NFC
Ralf Jung