Correct the const stabilization of `last_chunk` for slices
`<[T]>::last_chunk` should have become const stable as part of <https://github.com/rust-lang/rust/pull/117561>. Update the const stability gate to reflect this.
Add constants for f16 and f128
- Commit 1 adds associated constants for `f16`, excluding NaN and infinities as these are implemented using arithmetic for `f32` and `f64`.
- Commit 2 adds associated constants for `f128`, excluding NaN and infinities.
- Commit 3 adds constants in `std::f16::consts`.
- Commit 4 adds constants in `std::f128::consts`.
Document That `f16` And `f128` Hardware Support is Limited (v2)
This PR is identical to #123892, which was approved and merged but then removed from master by a force-push due to a [CI bug](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/ci.20broken.3F).
r? ghost
Original PR description:
---
This adds a small paragraph to the recently added f16 and f128 types explaining that hardware support may be limited, and that performance may suffer as a result of that.
I mainly wrote this because I felt it may be useful to express in some form; as a launchpoint for readers of the documentation if they have issues with performance.
I tried to word the documentation in a way that doesn't create false assumptions (that f16/f128 is too slow to use, for instance), removing the software implementation part could mislead people to thinking that f16/f128 is only available on some platforms, not all, so I believe it is important to keep in.\
"not all *major* platforms" is specifically said so as to not be redundant, because not all platforms implement many things, but the average rustacean is probably going to be using x86_64 or aarch64 derived ISA's, which is who this documentation is targeted towards.
I'm not sure of the best way to word the documentation, or if it should even be added, but I feel like it may be useful to have (potentially in a reworded way, I'm not very confident in the current wording and cannot decide if that is because it is too vague to be useful or too specific to be generally correct).
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
Update library/core/src/primitive_docs.rs
Remove orphaned doc link and clean up grammar a bit
Update library/core/src/primitive_docs.rs
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
Update library/core/src/primitive_docs.rs
Rewrite f16 and f128 hw support comments to match PR feedback
I wrote RISC-V allcaps in all cases, and wrote amd64 lowercase in all
cases, im not sure if either is the more correct way for either
platform, thats just how I normally write them, if theres a precedent
elsewhere it should probably be changed to match though.
Update library/core/src/primitive_docs.rs
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
Update library/core/src/primitive_docs.rs
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
Update library/core/src/primitive_docs.rs
Use `unchecked_sub` in `split_at`
LLVM currently isn't figuring it out on its own, even in the checked version where it hypothetically could.
Before: <https://rust.godbolt.org/z/PEY38YrKs>
```llvm
bb1: ; preds = %start
%4 = getelementptr inbounds float, ptr %x.0, i64 %n
%5 = sub i64 %x.1, %n
```
After:
```llvm
bb1: ; preds = %start
%4 = getelementptr inbounds float, ptr %x.0, i64 %n
%5 = sub nuw i64 %x.1, %n
```
This is not using the wrapper because there's already a ubcheck covering it, so I don't want this to get a second one once #121571 lands.
---
This is basically the same as #108763, since `split_at` is essentially doing two `get_unchecked`s.
Docs: suggest `uN::checked_sub` instead of check-then-unchecked
As of #124114 it's exactly the same in codegen, so might as well not use `unsafe`.
Note that this is only for *unsigned*, since the overflow conditions for `iN::checked_sub` are more complicated.
Remove an unnecessary cast
Very minor thing, obviously, but I randomly saw this unnecessary cast showing up in the UbChecks, so might as well get rid of it.
As of 124114 it's exactly the same in codegen, so might as well not use `unsafe`.
Note that this is only for *unsigned*, since the overflow conditions for `iN::checked_sub` are more complicated.
Stabilize `split_at_checked`
Closes#119128
For the const version of `slice::split_at_mut_checked`, I'm reusing the `const_slice_split_at_mut` feature flag (#101804). I don't if it okay to reuse tracking issues or if it preferred to create new ones...
Describe and use CStr literals in CStr and CString docs
Mention CStr literals in the description of both types, and use them in some of the code samples for CStr. This is intended to make C string literals more discoverable.
Additionally, I don't think the orange "This example is not tested" warnings are very encouraging, so I have made the examples on `CStr` build.
Implement ptr_as_ref_unchecked
Implementation of #122034.
Prefixed the feature name with `ptr_` for clarity.
Linked const-unstability to #91822, so the post there should probably be updated to mentions the 3 new methods when/if this PR is merged.
deref patterns: impl `DerefPure` for more std types
Context: [deref patterns](https://github.com/rust-lang/rust/issues/87121). The requirements of `DerefPure` aren't precise yet, but these types unambiguously satisfy them.
Interestingly, a hypothetical `impl DerefMut for Cow` that does a `Clone` would *not* be eligible for `DerefPure` if we allow mixing deref patterns with normal patterns. If the following is exhaustive then the `DerefMut` would cause UB:
```rust
match &mut Cow::Borrowed(&()) {
Cow::Owned(_) => ..., // Doesn't match
deref!(_x) if false => ..., // Causes the variant to switch to `Owned`
Cow::Borrowed(_) => ..., // Doesn't match
// We reach unreachable
}
```
Document never type fallback in `!`'s docs
Pulled the documentation I've written for #123939.
I want a single place where never type fallback is explained, which can be referred in all the lints and migration materials.
Use `target_vendor = "apple"` instead of `target_os = "..."`
Use `target_vendor = "apple"` instead of `all(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos")`.
The apple targets are quite close to being identical, with iOS, tvOS, watchOS and visionOS being even closer, so using `target_vendor` when possible makes it clearer when something is actually OS-specific, or just Apple-specific.
Note that `target_vendor` will [be deprecated in the future](https://github.com/rust-lang/rust/issues/100343), but not before an alternative (like `target_family = "apple"`) is available.
While doing this, I found various inconsistencies and small mistakes in the standard library, see the commits for details. Will follow-up with an extra PR for a similar issue that need a bit more discussion. EDIT: https://github.com/rust-lang/rust/pull/124494
Since you've talked about using `target_vendor = "apple"` in the past:
r? workingjubilee
CC `@simlay,` `@thomcc`
`@rustbot` label O-macos O-ios O-tvos O-watchos O-visionos
Fix#124478 - offset_of! returns a temporary
This was due to the must_use() call. Adding HIR's `OffsetOf` to the must_use checking within the compiler avoids this issue while maintaining the lint output.
Fixes#124478. `@tgross35`
Update `is_val_statically_known` Docs
* Add `Type Requirements` section, listing the allowed inputs, as requested by #121115
* Add `Pointers` subsection, explaining is_val_statically_known handles pointers.
* Add `Stability concerns` section, referring to other documentation relating to consistency in `const` functions.
Fixes#121115
Sorry this took so long.
