Add target-specific NaN payloads for the missing tier 2 targets
This PR adds target-specific NaN payloads for the remaining tier 2 targets:
- `arm64ec`: This target is a mix of `x86_64` and `aarch64`, meaning as they both have no extra payloads `arm64ec` also has no extra payloads.
- `loongarch64`: Per [LoongArch Reference Manual - Volume 1: Basic Architecture](https://github.com/loongson/LoongArch-Documentation/releases/download/2023.04.20/LoongArch-Vol1-v1.10-EN.pdf) section 3.1.1.3, LoongArch does quieting NaN propagation with the Rust preferred NaN as its default NaN, meaning it has no extra payloads.
- `nvptx64`: Per [PTX ISA documentation](https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#floating-point-instructions) section 9.7.3 (and section 9.7.4 for `f16`), all payloads are possible. The documentation explicitly states that `f16` and `f32` operations result in an unspecified NaN payload, while for `f64` it states "NaN payloads are supported" without specifying how or what payload will be generated if there are no input NaNs.
- `powerpc` and `powerpc64`: Per [Power Instruction Set Architecture](https://files.openpower.foundation/s/9izgC5Rogi5Ywmm/download/OPF_PowerISA_v3.1C.pdf) Book I section 4.3.2, PowerPC does quieting NaN propagation with the Rust preferred NaN being generated if no there are no input NaNs, meaning it has no extra payloads.
- `s390x`: Per [IBM z/Architecture Principles of Operation](https://www.vm.ibm.com/library/other/22783213.pdf#page=965) page 9-3, s390x does quieting NaN propagation with the Rust's preferred NaN as its default NaN, meaning it has no extra payloads.
Tracking issue: #128288
cc ``@RalfJung``
``@rustbot`` label +T-lang
Also cc relevant target maintainers of tier 2 targets:
- `arm64ec`: ``@dpaoliello``
- `loongarch64`: ``@heiher`` ``@xiangzhai`` ``@zhaixiaojuan`` ``@xen0n``
- `nvptx64`: ``@RDambrosio016`` ``@kjetilkjeka``
- `powerpc`: the only documented maintainer is ``@BKPepe`` for the tier 3 `powerpc-unknown-linux-muslspe`.
- `powerpc64`: ``@daltenty`` ``@gilamn5tr`` ``@Gelbpunkt`` ``@famfo`` ``@neuschaefer``
- `s390x`: ``@uweigand`` ``@cuviper``
simd intrinsics with mask: accept unsigned integer masks, and fix some of the errors
It's not clear at all why the mask would have to be signed, it is anyway interpreted bitwise. The backend should just make sure that works no matter the surface-level type; our LLVM backend already does this correctly. The note of "the mask may be widened, which only has the correct behavior for signed integers" explains... nothing? Why can't the code do the widening correctly? If necessary, just cast to the signed type first...
Also while we are at it, fix the errors. For simd_masked_load/store, the errors talked about the "third argument" but they meant the first argument (the mask is the first argument there). They also used the wrong type for `expected_element`.
I have extremely low confidence in the GCC part of this PR.
See [discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/257879-project-portable-simd/topic/On.20the.20sign.20of.20masks)
add next_index to Enumerate
Proposal: https://github.com/rust-lang/libs-team/issues/435
Tracking Issue: #130711
This basically just reopens#130682 but squashed and with the new function and the feature gate renamed to `next_index.`
There are two questions I have already:
- Shouldn't we add test coverage for that? I'm happy to provide some, but I might need a pointer to where these test would be.
- Maybe I could actually also add a doctest?
- For now, I just renamed the feature name in the unstable attribute to `next_index`, as well, so it matches the new name of the function. Is that okay? And can I just do that and use any string, or is there a sealed list of features defined somewhere where I also need to change the name?
Implement `pin!()` using `super let`
Tracking issue for super let: https://github.com/rust-lang/rust/issues/139076
This uses `super let` to implement `pin!()`.
This means we can remove [the hack](https://github.com/rust-lang/rust/pull/138717) we had to put in to fix https://github.com/rust-lang/rust/issues/138596.
It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.
While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.
It'd help [the experiment](https://github.com/rust-lang/rust/issues/139076) to have `pin!()` use `super let`, so we can get some more experience with it.
Fix drop handling in `hint::select_unpredictable`
This intrinsic doesn't drop the value that is not selected so this is manually done in the public function that wraps the intrinsic.
f*::NAN: guarantee that this is a quiet NaN
I think we should guarantee that this is a quiet NaN. This then implies that programs not using `f*::from_bits` (or unsafe type conversions) are guaranteed to only work with quiet NaNs. It would be awkward if people start to write `0.0 / 0.0` instead of using the constant just because they want to get a guaranteed-quiet NaN.
This is a `@rust-lang/libs-api` change. The definition of this constant currently is `0.0 / 0.0`, which is already guaranteed to be a quiet NaN. So all this does is forward that guarantee to our users.
Enable contracts for const functions
Use `const_eval_select!()` macro to enable contract checking only at runtime. The existing contract logic relies on closures, which are not supported in constant functions.
This commit also removes one level of indirection for ensures clauses since we no longer build a closure around the ensures predicate.
Resolves#136925
**Call-out:** This is still a draft PR since CI is broken due to a new warning message for unreachable code when the bottom of the function is indeed unreachable. It's not clear to me why the warning wasn't triggered before.
r? ```@compiler-errors```
Avoid unused clones in `Cloned<I>` and `Copied<I>`
Avoid cloning in `Cloned<I>` or copying in `Copied<I>` when elements are only needed by reference or not at all. There is already some precedent for this, given that `__iterator_get_unchecked` is implemented, which can skip elements. The reduced clones are technically observable by a user impl of `Clone`.
r? libs-api
* "while until either" could also be changed to "for a while until either", but I just deleted "while".
* fixed sentence with incorrect "at" and "has/have".
* linked [*currently allocated*] similar to other methods.
If you want to logically split an iterator after `n` items, you might first
discover `take`. Before this change, you'd find that `take` consumes the
iterator, and you'd probably be stuck. The answer involves `by_ref`, but that's
hard to discover, especially since `by_ref` is a bit abstract and `Iterator`
has many methods.
After this change, you'd see the example showing `take` along with `by_ref`,
which allows you to continue using the rest of the iterator. `by_ref` had a
good example involving `take` already, so this change just duplicates that
existing example under `take`.
Avoid cloning in `Cloned<I>` or copying in `Copied<I>` when elements are
only needed by reference or not at all. There is already some precedent
for this, given that `__iterator_get_unchecked` is implemented, which
can skip elements. The reduced clones are technically observable by a
user impl of `Clone`.
Initial `UnsafePinned` implementation [Part 1: Libs]
Initial libs changes necessary to unblock further work on [RFC 3467](https://rust-lang.github.io/rfcs/3467-unsafe-pinned.html).
Tracking issue: #125735
This PR is split off from #136964, and includes just the libs changes:
- `UnsafePinned` struct
- private `UnsafeUnpin` structural auto trait
- Lang items for both
- Compiler changes necessary to block niches on `UnsafePinned`
This PR does not change codegen, miri, the existing `!Unpin` hack, or anything else. That work is to be split into later PRs.
---
cc ``@RalfJung`` ``@Noratrieb``
``@rustbot`` label F-unsafe_pinned T-libs-api
Move `select_unpredictable` to the `hint` module
There has been considerable discussion in both the ACP (rust-lang/libs-team#468) and tracking issue (#133962) about whether the `bool::select_unpredictable` method should be in `core::hint` instead.
I believe this is the right move for the following reasons:
- The documentation explicitly says that it is a hint, not a codegen guarantee.
- `bool` doesn't have a corresponding `select` method, and I don't think we should be adding one.
- This shouldn't be something that people reach for with auto-completion unless they specifically understand the interactions with branch prediction. Using conditional moves can easily make code *slower* by preventing the CPU from speculating past the condition due to the data dependency.
- Although currently `core::hint` only contains no-ops, this isn't a hard rule (for example `unreachable_unchecked` is a bit of a gray area). The documentation only status that the module contains "hints to compiler that affects how code should be emitted or optimized". This is consistent with what `select_unpredictable` does.
Use the chaining methods on PartialOrd for slices too
#138135 added these doc-hidden trait methods to improve the tuple codegen. This PR adds more implementations and callers so that the codegen for slice (and array) comparisons also improves.
docs: clarify uint exponent for `is_power_of_two`
This makes the documentation more explicit for that method. I know this might seem "nit-picky", but `k` could be interpreted as "any Real or Complex number". A trivial example would be $`3 = 2^{log_2(3)}`$ which "proves that three is a power of two" (according to that vague definition).
BTW, when I read the implementation, I was surprised to see that `1` is considered a power of 2 despite being odd (it does make sense in some contexts, but still not intuitive). So I wrote "positive int" before correcting it to "unsigned int"
