Guarantee behavior of transmuting `Option::<T>::None` subject to NPO
In https://github.com/rust-lang/rust/pull/115333, we added a guarantee that transmuting from `[0u8; N]` to `Option<P>` is sound where `P` is a pointer type subject to the null pointer optimization (NPO). It would be useful to be able to guarantee the inverse - that a `None::<P>` value can be transmutes to an array and that will yield `[0u8; N]`.
Closes#117591
Updated std doctests for wasm
This updates some doctests that fail to run on wasm. We will soon be supporting cross-compiled doctests, and the test-various job fails to run these tests. These tests fail because wasm32-wasip1 does not support threads.
Rollup of 7 pull requests
Successful merges:
- #135562 (Add ignore value suggestion in closure body)
- #139635 (Finalize repeat expr inference behaviour with inferred repeat counts)
- #139668 (Handle regions equivalent to 'static in non_local_bounds)
- #140218 (HIR ty lowering: Clean up & refactor the lowering of type-relative paths)
- #140435 (use uX::from instead of _ as uX in non - const contexts)
- #141130 (rustc_on_unimplemented cleanups)
- #141286 (Querify `coroutine_hidden_types`)
Failed merges:
- #140247 (Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs)
r? `@ghost`
`@rustbot` modify labels: rollup
limit impls of `VaArgSafe` to just types that are actually safe
tracking issue: https://github.com/rust-lang/rust/issues/44930
Retrieving 8- or 16-bit integer arguments from a `VaList` is not safe, because such types are subject to upcasting. See https://github.com/rust-lang/rust/issues/61275#issuecomment-2193942535 for more detail.
This PR also makes the instances of `VaArgSafe` visible in the documentation, and uses a private sealed trait to make sure users cannot create additional impls of `VaArgSafe`, which would almost certainly cause UB.
r? `@workingjubilee`
8 and 16-bit integers are subject to upcasting in C, and hence are not reliably safe. users should perform their own casting and deal with the consequences
Implement `ptr::try_cast_aligned` and `NonNull::try_cast_aligned`.
Implement three common methods on raw pointers and `NonNull`s: `try_cast_aligned`.
## Related links
- Tracking Issue: https://github.com/rust-lang/rust/issues/141221
## About `#[inline]`
Since the result of a call to `align_of` is a power of two known at compile time, the compiler is able to reduce a call to `try_cast_aligned` to only test and sete (or test and jne if followed by `unwrap`), at least on every tier 1 target's arch. This seemed like a good reason to `#[inline]` the function.
- https://godbolt.org/z/ocehvPWMx (raw inlining)
- https://godbolt.org/z/3qa4j4Yrn (comparison with no inlining)
use `Self` alias in self types rather than manually substituting it
Of the rougly 145 uses of `self: Ty` in the standard library, 5 of them don't use `Self` but instead choose to manually "substitute" the `impl`'s self type into the type.
This leads to weird behavior sometimes (https://github.com/rust-lang/rust/issues/140611#issuecomment-2883761300) -- **to be clear**, none of these usages actually trigger any bugs, but it's possible that they may break in the future (or at least lead to lints), so let's just "fix" them proactively.
`core_float_math`: Move functions to `math` module
When these functions were added in https://github.com/rust-lang/rust/pull/138087 It made a relatively common pattern for emulating these functions using an extension trait (which internally uses `libm`) much more fragile. If `core::f32` happened to be imported by the user (to access a constant, say), then that import in the module namespace would take precedence over the `f32` in the type namespace for resolving these functions, running headfirst into the stability attribute.
We ran into this in [Color](https://github.com/linebender/color) and chose to release the remedial 0.3.1 and 0.2.4, to allow downstream crates to build on `docs.rs`.
As these methods are perma-unstable, moving them into a new module should not have any long-term concerns, and ensures that this "breakage" doesn't adversely impact anyone else.
I believe that I've made the module unstable correctly. I presume that this does not require a test to make sure stable code can't depend on the module existing?
I've left the stability attribute on each function - happy to tweak this if a different pattern is more correct.
Tracking issue for `core_float_math`: https://github.com/rust-lang/rust/issues/137578.
This PR is as requested in https://github.com/rust-lang/rust/pull/138087.
r? `@tgross35`
Recommended reviewing with whitespace hidden.
(This is my first PR to `std/core`/this repository, as far as I can remember)
When these functions were added in
https://github.com/rust-lang/rust/pull/138087
It made a relatively common pattern for emulating
these functions using an extension trait (which
internally uses `libm`) much more fragile.
If `core::f32` happened to be imported by the user
(to access a constant, say), then that import in
the module namespace would take precedence over
`f32` in the type namespace for resolving these
functions, running headfirst into the stability
attribute.
We ran into this in Color -
https://github.com/linebender/color - and chose to
release the remedial 0.3.1 and 0.2.4, to allow
downstream crates to build on `docs.rs`.
As these methods are perma-unstable, moving them
into a new module should not have any long-term
concerns, and ensures that this breakage doesn't
adversely impact anyone else.
Stabilize the avx512 target features
This PR stabilizes the AVX512 target features - see [this comment](https://github.com/rust-lang/rust/issues/111137#issuecomment-2745821279).
Tracking Issue - #44839
The target feature UI tests have been changed to `x87` (chosen because this is very unlikely to stablize ever, please comment if some other feature will be better)
related: #111137
Use the existing Lemire (decimal -> float) and Dragon / Grisu algorithms
(float -> decimal) to add support for `f16`. This allows updating the
implementation for `Display` to the expected behavior for `Display`
(currently it prints the a hex bitwise representation), matching other
floats, and adds a `FromStr` implementation.
In order to avoid crashes when compiling with Cranelift or on targets
where f16 is not well supported, a fallback is used if
`cfg(target_has_reliable_f16)` is not true.
Initial implementation of `core_float_math`
Since [1], `compiler-builtins` makes a certain set of math symbols
weakly available on all platforms. This means we can begin exposing some
of the related functions in `core`, so begin this process here.
It is not possible to provide inherent methods in both `core` and `std`
while giving them different stability gates, so standalone functions are
added instead. This provides a way to experiment with the functionality
while unstable; once it is time to stabilize, they can be converted to
inherent.
For `f16` and `f128`, everything is unstable so we can move the inherent
methods.
The following are included to start:
* floor
* ceil
* round
* round_ties_even
* trunc
* fract
* mul_add
* div_euclid
* rem_euclid
* powi
* sqrt
* abs_sub
* cbrt
These mirror the set of functions that we have in `compiler-builtins`
since [1], with the exception of `powi` that has been there longer.
Details for each of the changes is in the commit messages.
Tracking issue: https://github.com/rust-lang/rust/issues/137578
[1]: https://github.com/rust-lang/compiler-builtins/pull/763
try-job: aarch64-gnu
tru-job: armhf-gnu
try-job: i686-msvc-1
try-job: test-various
try-job: x86_64-mingw-1
try-job: x86_64-mingw-2
Add as_ascii_unchecked() methods to char, u8, and str
This PR adds the `as_ascii_unchecked()` method to `char`, `u8`, and `str`, allowing users to convert these types to `ascii::Char`s (see #110998) in an `unsafe` context without first checking for validity. This method was already available for `[u8]`, so this PR makes the API more consistent across other types.
Add `#[must_use]` to Array::map
The output of Array::map is intended to be an array of the same size, and does not modify the original in place nor is it intended for side-effects. Thus, under normal circumstances it should be consumed.
See [discussion](https://internals.rust-lang.org/t/array-map-annotate-with-must-use/22813/26).
Attaching to tracking issue #75243
std: explain prefer `TryInto` over `TryFrom` when specifying traits bounds on generic function
Fixes#140761
This PR keeps the explanations of `Into` and `From` consistent and adds explanations for `TryInto` and `TryFrom`.
r? libs
This updates some doctests that fail to run on wasm. We will soon be
supporting cross-compiled doctests, and the test-various job fails to
run these tests. These tests fail because wasm32-wasip1 does not support
threads.
docs(library/core/src/pin): fix typo "necessarily" -> "necessary"
Fix a typo in [`library/core/src/pin.rs`](14662fabeb/library/core/src/pin.rs), from
> As we'll see later, this is **necessarily** from the time the value is first pinned until the end of its lifespan.
to
> As we'll see later, this is **necessary** from the time the value is first pinned until the end of its lifespan.
(my emphasis).
MaybeUninit::write: fix doc
# Fix doc for `MaybeUninit::write`
The documentation refers to the way `MaybeUninit` stores data internally. The property of not dropping content on context exit is the responsibility of `ManuallyDrop`.
