You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Relates to #45440. If we can get them to propagate properly through inline(always) functions, we would be able to write a "safe" wrapper around them that we can stabilize.
These are far from the only intrinsics that are safe, but there's currently no way to make intrinsics safe (short of a safe wrapper). I think I saw an issue about this at some point but I can't find it now.
@jbayardo AFAIK you can also attach the #[allow(unused_unsafe)] to the macro declaration, it should work too. The entire macro can theoretically be exposed by the standard library.
That did not work for me. I believe this shouldn't be a macro though, the likely/unlikely intrinsics should just be safe; the #allow(unused_unsafe) won't warn you in cases like
You can't just mark intrinsics safe, because all intrinsics are extern "rust-intrinsic" functions and extern functions are always unsafe to call. Changing that would require some new language feature, e.g., as proposed by #1248.
As mentioned, there are many other intrinsics that should not require unsafe. This is going to need an RFC around how to expose intrinsics that are safe to call. One previous RFC on this topic was closed rust-lang/rfcs#1248 (comment) but the lang team plans to follow up by merging the idea of "intrinsic" and "lang item", at which point likely and unlikely would be exposed as safe to call.
Activity
gnzlbg commentedon Oct 22, 2017
Relates to #45440. If we can get them to propagate properly through inline(always) functions, we would be able to write a "safe" wrapper around them that we can stabilize.
hanna-kruppe commentedon Oct 22, 2017
These are far from the only intrinsics that are safe, but there's currently no way to make intrinsics safe (short of a safe wrapper). I think I saw an issue about this at some point but I can't find it now.
est31 commentedon Oct 22, 2017
For safe wrappers for likely/unlikely intrinsics, one can also do macros with
allow_internal_unsafe
: see it live:You can pair it with
allow_internal_unstable
to expose stableunlikely
/likely
macros!jbayardo commentedon Oct 23, 2017
The snippet by @est31 should be:
And requires
In order to work seamlessly as of today's nightly (in the case of likely/unlikely used within unsafe blocks).
est31 commentedon Oct 23, 2017
@jbayardo AFAIK you can also attach the
#[allow(unused_unsafe)]
to the macro declaration, it should work too. The entire macro can theoretically be exposed by the standard library.jbayardo commentedon Oct 23, 2017
That did not work for me. I believe this shouldn't be a macro though, the likely/unlikely intrinsics should just be safe; the
#allow(unused_unsafe)
won't warn you in cases likehanna-kruppe commentedon Oct 23, 2017
You can't just mark intrinsics safe, because all intrinsics are
extern "rust-intrinsic"
functions and extern functions are always unsafe to call. Changing that would require some new language feature, e.g., as proposed by #1248.dtolnay commentedon Nov 14, 2017
As mentioned, there are many other intrinsics that should not require unsafe. This is going to need an RFC around how to expose intrinsics that are safe to call. One previous RFC on this topic was closed rust-lang/rfcs#1248 (comment) but the lang team plans to follow up by merging the idea of "intrinsic" and "lang item", at which point
likely
andunlikely
would be exposed as safe to call.