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
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, _>
```
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
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
We specifically call out that the sign is written for negative
integers. This would also ideally be called out in `<iN>::format_into`,
but the macro infrastructure for the implementation unfortunately
doesn't really make this easy as far as I can tell.
Widen the result of `widening_mul`.
Tracking issue: rust-lang/rust#152016
This PR implements <https://github.com/rust-lang/rust/issues/152016#issuecomment-3843258926>, which mandates that `widening_mul` return a single, scalar value rather than a low/high tuple.
Consequently, this method is removed from `u128` and `i128` as they are the widest integral types. It has also been removed from `usize` and `isize` due to portability concerns.
Existing `widening_mul` usage has been replaced by equivalent calls to `carrying_mul` (which is logically identical to the old behaviour.) Existing – generic – non-doc tests have been removed.
# Public API
```rust
impl u8 {
pub const fn widening_mul(self, rhs: Self) -> u16;
}
impl u16 {
pub const fn widening_mul(self, rhs: Self) -> u32;
}
impl u32 {
pub const fn widening_mul(self, rhs: Self) -> u64;
}
impl u64 {
pub const fn widening_mul(self, rhs: Self) -> u128;
}
impl i8 {
pub const fn widening_mul(self, rhs: Self) -> i16;
}
impl i16 {
pub const fn widening_mul(self, rhs: Self) -> i32;
}
impl i32 {
pub const fn widening_mul(self, rhs: Self) -> i64;
}
impl i64 {
pub const fn widening_mul(self, rhs: Self) -> i128;
}
```
Add pext/pdep as aliases for extract_bits/deposit_bits
So that the methods will be found when searching for the corresponding intrinsics.
Tracking issue for `extract_bits`/`deposit_bits`: https://github.com/rust-lang/rust/issues/149069
Derives `Copy` for `ffi::FromBytesUntilNulError`
[`ffi::FromBytesWithNulError` derives `Copy` since Rust 1.93](https://github.com/rust-lang/rust/commit/2f5a3d4b06a0a9e8749c2e361758ec517df0c96a) while `ffi::FromBytesUntilNulError` doesn't.
This Pr fixes that by deriving `Copy` for `ffi::FromBytesUntilNulError`.
I encountered this issue while I was working in a const context.
Note: I couldn't find any documentation about what kind of PR is allowed. As this one is very small, I guess it is ok to submit it directly without opening an issue first?
Remove `UncheckedIterator`
The only remaining usage of `UncheckedIterator` was in `array::{try_,}from_trusted_iterator`. So, replace `array::repeat` and array's `Clone` impl with a manual `from_fn` call rather than going through unnecessary abstractions, and remove the `UncheckedIterator` trait.
Implement `OsStr::split_at`
See rust-lang/rust#156199
This allows splitting only on valid UTF-8 boundaries, regardless of the platform, which avoids cross-platform landmines.
Fix typo in `format_into` docs: signed -> unsigned
The documentation for the `format_into` methods on unsigned integers
still said "in signed decimal format". Change them to say "unsigned".
Change division to multiplication in floating-point midpoint
Multiplication is faster than division on most (all?) platforms. While the optimizer will handle this, there is really no point in relying on that. Using multiplication directly will not have any drawbacks and are numerically identical (in this case since 1.0 / 2.0 == 0.5)
Consider the examples at https://godbolt.org/z/oMvb9vobG where it is clear that the non-optimized version uses division, while the optimized version uses multiplication.
This is the only remaining place that uses `UncheckedIterator`. So,
replace `array::repeat` and array's `Clone` impl with a manual `from_fn`
call rather than going through unnecessary abstractions.
Removal of `UncheckedIterator` will be done in a later commit.
Move `std::io::util` to `core::io`
ACP: https://github.com/rust-lang/libs-team/issues/755
Tracking issue: https://github.com/rust-lang/rust/issues/154046
Subset of: https://github.com/rust-lang/rust/pull/154684
## Description
Moves utility types and functions from `std::io::util` and `std::io` to `core::io`, leaving any IO trait implementations behind. They will be moved along with the traits themselves. Certain documentation links had to be amended.
- `Chain`
- `Empty`
- `Repeat`
- `Sink`
- `Take`
- `empty`
- `repeat`
- `sink`
---
## Notes
* This can be reviewed independently of the other PRs tracked in rust-lang/rust#154046.
* `Chain` and `Take` were previously in the main `mod.rs` file for `std::io`, but I've chosen to move them into the `util.rs` file in `core::io` instead. I think they make more sense in that file, but I'm happy to move them into `mod.rs` if that's a controversial decision.
* No AI tooling of any kind was used during the creation of this PR.
Matthias Krüger