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.
Allow the global allocator to use thread-local storage and std:🧵:current()
Fixes https://github.com/rust-lang/rust/issues/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 https://github.com/rust-lang/rust/pull/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`
Remove outdated part of comment claiming thread_local re-enters global allocator
Fix typo in doc comment
Add comments for guarantees given and footnote that System may still be called
Revise mention of using the global allocator
Allow for the possibility that the global allocator is the system allocator.
Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>
Rename `DropGuard::into_inner` to `DropGuard::dismiss`
Tracking issue: https://github.com/rust-lang/rust/issues/144426
One of the open questions blocking the stabilization of `DropGuard` is what to name the associated method that prevents the destructor from running, and returns the captured value. This method is currently called `into_inner`, but most people (including myself) feel like this would benefit from a method that calls more attention to itself.
This PR proposes naming this method `dismiss`, after the Linux kernel's [`ScopeGuard::dismiss`](https://rust.docs.kernel.org/kernel/types/struct.ScopeGuard.html#method.dismiss). Which crucially does not evoke images of violence or weaponry the way alternatives such as "disarm" or "defuse" do. And personally I enjoy the visual metaphor of "dismissing a guard" (e.g. a person keeping watch over something) - a job well done, they're free to go.
This PR also changes the signature from an static method to an instance method. This also matches the Linux kernel's API, and seems alright since `dismiss` is not nearly as ubiquitous as `into_inner`. This makes it more convenient to use, with a much lower risk of conflicting. Though in the rare case there might be ambiguity, the explicit notation is available as a fallback.
```rust
let x = DropGuard::into_inner(guard); // ← current
let x = guard.dismiss(); // ← proposed
Suggest _bytes versions of endian-converting methods
As pointed out [in this article](https://purplesyringa.moe/blog/ntoh-hton-is-a-bad-api/), the `int.to_be()`/`int.to_le()` functions are technically returning a wrong type, because endian-specific representations of integers and Rust's always-native-endian integers are different things.
I wanted to make the docs state more directly that byte swapping will result in the type having a "wrong" value, but I wasn't sure whether to delve into the special case of palindrome-like values (`0x12343412`) not changing.
I've updated the docs to suggest `{to,from}_[lb]e_bytes()` instead. These methods use `[u8; _]` for endian-specific representations, which is a different type than the native-endian `u16`/`u32`/`u64`, and this is a type-safety improvement.
float:🗜️ make treatment of signed zeros unspecified
Fixes https://github.com/rust-lang/rust/issues/83984 by explicitly documenting that we do not specify the treatment of signed zeros in `clamp`. `@rust-lang/libs-api` Is this what you'd like to see?
Cc `@tgross35` `@thomcc`
clarify float min/max behavios for NaNs and signed zeros
The first comment is internal, it only documents the intrinsics to more clearly say what they do.
This makes the currently implemented semantics more explicit, so one does not have to go look for the publicly exposed version of the operation to figure out what exactly should happen.
The second commit adds a NaN test to the doc comment for `min`/`max`, which matches what we already have for `minimum`/`maximum`.
Add a diagnostic attribute for special casing const bound errors for non-const impls
Somewhat of a follow-up to https://github.com/rust-lang/rust/pull/144194
My plan is to resolve
f4e19c6878/compiler/rustc_hir_typeck/src/callee.rs (L907-913)
but doing so without being able to mark impls the way I do in this PR wrould cause all nice diagnostics about for loops and pointer comparisons to just be a `*const u32 does not implement [const] PartialEq` errors.
Stabilize `maybe_uninit_write_slice`
Stabilize feature `maybe_uninit_write_slice` (closes https://github.com/rust-lang/rust/issues/79995).
Note that this also const-stabilizes `<[MaybeUninit<_>]>::write_copy_of_slice`. That method depends on `<[_]>::copy_from_slice`, which is already const-stable, and `<[MaybeUninit<_>]>::assume_init_mut` which is now also stable.
See if this is the time we can remove `layout::size_align`
This was a bad idea before, but now that `size_of` and `align_of` work completely differently than when removing it was first tried in 2020, maybe it makes sense now.
(Or maybe I'll just add another attempt to the list in the comments...)
r? ghost
Add doc for va_list APIs
I observed that [PR146521](https://github.com/rust-lang/rust/pull/146521) submitted two weeks ago resolved some documentation issues related to `VaListImpl`, similar to the previous [PR136969](https://github.com/rust-lang/rust/pull/136969).
This PR specifically adds requirements about argument availability for `VaListImpl::arg`, and also adds safety descriptions to the three associated intrinsic APIs.
stdarch subtree update
Subtree update of `stdarch` to 50134e10cb.
Created using https://github.com/rust-lang/josh-sync.
The only interesting commit is the final one, which enables the `avx10_target_feature` feature in the standard library, because it is now used in `stdarch`.
r? `@sayantn` (or whoever, this is just a straightforward sync)
This was a bad idea before, but now that `size_of` and `align_of` work completely differently than when removing it was first tried in 2020, maybe it makes sense now.
(Or maybe I'll just add another attempt to the list in the comments...)
feat: Add `bit_width` for unsigned `NonZero<T>`
- Tracking issue: rust-lang/rust#142326
This pull request adds a method to the unsigned `NonZero<T>` that return the minimum number of bits required to represent a value.
This can be achieved by using the `get` method and the methods added in rust-lang/rust#142328, but I think adding the `NonZero::bit_width` method is useful because it accomplishes the same thing a little more succinctly.
Make SIMD intrinsics available in `const`-contexts
successor to rust-lang/rust#146568, this PR actually makes the SIMD intrinsics `const`, and modifies the tests to test the const-eval implementations
r? `@tgross35` ig (although feel free to reassign, this is not anything targeted really)
