Make missed precondition-free float intrinsics safe #146915
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
rustbot
added
the
T-libs
clarfonthey
commented
Sep 23, 2025
| /// [`f16::abs`](../../std/primitive.f16.html#method.abs) | ||
| #[rustc_nounwind] | ||
| #[rustc_intrinsic] | ||
| pub const unsafe fn fabsf16(x: f16) -> f16; |
There was a problem hiding this comment.
Side remark: fabsf16 and fabsf128 aren't used in their corresponding fn abs definitions, so, I'm assuming they're "not ready yet" in that sense. However, they can still be marked safe for consistency.
jfrimmel
reviewed
Sep 23, 2025
|
r=me with that comment removed. |
clarfonthey
force-pushed
the
safe-intrinsics-2
branch
from
4260757 to
e8a8e06
Compare
|
Comment is now fixed |
|
Thanks! |
bors
added
S-waiting-on-bors
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Sep 24, 2025
…alfJung Make missed precondition-free float intrinsics safe So, in my defence, these were both separated out from the other intrinsics in the file *and* had a different safety comment in the stable versions, so, I didn't notice them before. But, in my offence, the entire reason I did the previous PR was because I was using them for SIMD intrinsic fallbacks, and `fabs` is needed for those too, so, I don't really have an excuse. Extra follow-up to rust-lang#146683. r? `@RalfJung` who reviewed the previous one These don't appear to be used anywhere outside of the standard locations, at least.
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Sep 24, 2025
…alfJung Make missed precondition-free float intrinsics safe So, in my defence, these were both separated out from the other intrinsics in the file *and* had a different safety comment in the stable versions, so, I didn't notice them before. But, in my offence, the entire reason I did the previous PR was because I was using them for SIMD intrinsic fallbacks, and `fabs` is needed for those too, so, I don't really have an excuse. Extra follow-up to rust-lang#146683. r? ``@RalfJung`` who reviewed the previous one These don't appear to be used anywhere outside of the standard locations, at least.
bors
added a commit
that referenced
this pull request
Sep 24, 2025
Rollup of 9 pull requests Successful merges: - #146711 (fix 2 borrowck issues) - #146735 (unstably constify float mul_add methods) - #146857 (revert change removing `has_infer` check. Commit conservatively patch…) - #146897 (fix ICE in rustdoc::invalid_html_tags) - #146915 (Make missed precondition-free float intrinsics safe) - #146932 (Switch next-solver related rustc dependencies of r-a to crates.io ones) - #146959 (temporary-lifetime-extension-tuple-ctor.rs: make usable on all editions) - #146964 (library: std: sys: pal: uefi: Add some comments) - #146969 (const-eval: better wording for errors involving maybe-null pointers) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
that referenced
this pull request
Sep 24, 2025
Rollup of 8 pull requests Successful merges: - #146711 (fix 2 borrowck issues) - #146857 (revert change removing `has_infer` check. Commit conservatively patch…) - #146897 (fix ICE in rustdoc::invalid_html_tags) - #146915 (Make missed precondition-free float intrinsics safe) - #146932 (Switch next-solver related rustc dependencies of r-a to crates.io ones) - #146959 (temporary-lifetime-extension-tuple-ctor.rs: make usable on all editions) - #146964 (library: std: sys: pal: uefi: Add some comments) - #146969 (const-eval: better wording for errors involving maybe-null pointers) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
that referenced
this pull request
Sep 24, 2025
Rollup merge of #146915 - clarfonthey:safe-intrinsics-2, r=RalfJung Make missed precondition-free float intrinsics safe So, in my defence, these were both separated out from the other intrinsics in the file *and* had a different safety comment in the stable versions, so, I didn't notice them before. But, in my offence, the entire reason I did the previous PR was because I was using them for SIMD intrinsic fallbacks, and `fabs` is needed for those too, so, I don't really have an excuse. Extra follow-up to #146683. r? ```@RalfJung``` who reviewed the previous one These don't appear to be used anywhere outside of the standard locations, at least.
github-actions bot
pushed a commit
to rust-lang/rust-analyzer
that referenced
this pull request
Sep 25, 2025
Rollup of 8 pull requests Successful merges: - rust-lang/rust#146711 (fix 2 borrowck issues) - rust-lang/rust#146857 (revert change removing `has_infer` check. Commit conservatively patch…) - rust-lang/rust#146897 (fix ICE in rustdoc::invalid_html_tags) - rust-lang/rust#146915 (Make missed precondition-free float intrinsics safe) - rust-lang/rust#146932 (Switch next-solver related rustc dependencies of r-a to crates.io ones) - rust-lang/rust#146959 (temporary-lifetime-extension-tuple-ctor.rs: make usable on all editions) - rust-lang/rust#146964 (library: std: sys: pal: uefi: Add some comments) - rust-lang/rust#146969 (const-eval: better wording for errors involving maybe-null pointers) r? `@ghost` `@rustbot` modify labels: rollup
github-actions bot
pushed a commit
to model-checking/verify-rust-std
that referenced
this pull request
Oct 9, 2025
…alfJung Make missed precondition-free float intrinsics safe So, in my defence, these were both separated out from the other intrinsics in the file *and* had a different safety comment in the stable versions, so, I didn't notice them before. But, in my offence, the entire reason I did the previous PR was because I was using them for SIMD intrinsic fallbacks, and `fabs` is needed for those too, so, I don't really have an excuse. Extra follow-up to rust-lang#146683. r? ```@RalfJung``` who reviewed the previous one These don't appear to be used anywhere outside of the standard locations, at least.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So, in my defence, these were both separated out from the other intrinsics in the file and had a different safety comment in the stable versions, so, I didn't notice them before. But, in my offence, the entire reason I did the previous PR was because I was using them for SIMD intrinsic fallbacks, and
fabsis needed for those too, so, I don't really have an excuse.Extra follow-up to #146683.
r? @RalfJung who reviewed the previous one
These don't appear to be used anywhere outside of the standard locations, at least.