Add `TypeId` methods `variants` `fields` `field` for `type_info`
Tracking issue rust-lang/rust#146922
- Adds `fn TypeId::variants` returns the number of variants, for struct and union and primitive types, it's always 1.
- Adds `fn TypeId::fields` returns the number of fields.
- Adds `fn TypeId::field` returns a field representing type `FieldId`.
- Adds a new type `FieldId`, which is a wrapper of `FieldRepresentingType`'s `TypeId`.
For methods `{fields,field}`, if indexing out of bounds, a compile-time error will be raised.
Regarding the removal of `Type` items, this will be done in a later PR in one go.
r? @oli-obk
std::net::tcp: let the OS pick the port numbers
See rust-lang/rust#156377 for context.
I only did the TCP tests for now to see whether there are any unexpected problems.
rustc_on_unimplemented: introduce format specifiers
...as printing options for the annotated item.
See also the test and dev guide prose. This only affects rustc_on_unimplemented, not (yet) the other diagnostic attributes. I plan to do that in some later PR.
```rust
#![feature(rustc_attrs)]
#[rustc_on_unimplemented(
message = "normal: {This}, path: {This:path}, resolved: {This:resolved}"
)]
pub trait Trait<'lifetime, const CONST_GENERIC: usize, A, B> where A: Send {}
```
will do:
```
normal: Trait, path: Trait<'lifetime, CONST_GENERIC, A, B>, resolved: Trait<'_, 6, u8, _>
```
`powerpc64-unknown-linux-gnu` currently is an ELFv1 target, while
`powerpc64-unknown-linux-musl` is an ELFv2 target.
Big-endian and little-endian ELFv2 targets both behave normally: they emit
`.note.GNU-stack`. Therefore, currently the tests would fail on big-endian
powerpc64 with ELFv2 ABI.
To determine whether we need to special-case powerpc64, we should check
the ABI instead of the endianness. The problem here is that the `e_flags`
part of the ELF header is actually `0` in the output of `cc -O0
-ffunction-sections -fdata-sections -fPIC -m64 -mabi=elfv2 -Wall -Wextra
-o missing_gnu_stack_section.o -c missing_gnu_stack_section.S`, the output
of that command is bit-for-bit identical on ELFv1 and ELFv2 hosts. In
order to know when to allow an unset `.note.GNU-stack` we therefore must
set `.abiversion 2` to be able to tell them apart from the ELF header.
This makes all tests pass on `powerpc64-unknown-linux-musl`.
Clang and GCC use char and short for the data parameter type where
appropriate. The LLVM intrinsics take an i32. We should match clang and
perform a cast here.
Fix doc typo in Vec::into_array and convert Arc/Box/Rc::into_arry to -> Result
Hello 🪼,
the first commit fixes a documentation mistake added in the recent PR rust-lang/rust#156234
The second commit addresses three function signature changes as defined by the tracking issue rust-lang/rust#148082
It converts all `.into_array() -> Option<>` into `.into_array() -> Result<>`
The third commit is a fixup for the second. The change is needed as calling `unwrap()` on `Err(E)` requires `E` to implement `Debug`. I thought `Vec<T, A> where T: Debug` is not an acceptable solution, so I tried to come up with my own. I am *NOT* confident in my `unsafe {}` code due to lack of expierence, please check extra carefully.
Appreciating feedback & greetings from the RustWeek,
Thanks!
Add `#[doc(alias = "phi")]` for float `GOLDEN_RATIO` constants
- Adds "phi" doc alias for `f16`, `f32`, `f64`, and `f128`
I knew this constant was stabilized but I couldn't remember what it was called.
Searching "phi" in the docs only surfaces the π constant, `is_ascii_graphic`, and `spin_loop_hint` methods. This alias would make it much easier to find.
https://doc.rust-lang.org/nightly/std/?search=phi
Add unstable Share trait
Tracking issue: rust-lang/rust#156756
This adds an initial unstable `Share` trait for clone-as-alias types, as part of the 2026 ergonomic ref-counting project goal.
```rust
pub trait Share: Clone {
fn share(&self) -> Self {
Clone::clone(self)
}
}
```
This PR adds a separate unstable feature gate:
```rust
#![feature(share_trait)]
```
and places the trait next to `Clone` in `core::clone`.
Implemented initial impls:
- `impl<T: ?Sized> Share for &T`
- `impl<T: ?Sized, A: Allocator + Clone> Share for Rc<T, A>`
- `impl<T: ?Sized, A: Allocator + Clone> Share for Arc<T, A>`
- `impl<T> Share for std::sync::mpsc::Sender<T>`
- `impl<T> Share for std::sync::mpsc::SyncSender<T>`
The PR deliberately does not add `Share` to the prelude.
r? @nikomatsakis
@rustbot label F-ergonomic_clones
Remove unsound `target_feature_inline_always` feature
## Summary
- Remove `target_feature_inline_always`
- Update stdarch generators to only use `#[inline]` & regenerate stdarch.
## Why?
Succinctly; the feature relies on LLVMs `AlwaysInlinerPass()` running before LLVMs heuristic based inliner pass. Which is not a basis for sound code.
This has been discussed in [the tracking issue](https://github.com/rust-lang/rust/issues/145574).
If the ordering of the passes were to change, of which they have in the past, it is very possible we could inline functions across callsites with mismatching target features leading to unsound code. Checks proposed in; https://github.com/rust-lang/rust/pull/155426 would only take into account caller -> callee which is not enough to guard against possibly of generating unsound code if the pass ordering were to change.
There doesn't seem to be a way, presently, this this mechanism to provide soundness guarantees nor does it seem like `AlwaysInlinerPass()` is a desired feature of LLVM, which this feature relies on.
r? @RalfJung
Matthias Krüger