-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stabilize target_feature_11 #134090
base: master
Are you sure you want to change the base?
Stabilize target_feature_11 #134090
Conversation
"whatever"? |
Ralf requested this on Zulip. I do not see that such a rejustification is included, and I agree that it should be. An assertion of "we do not expect problems from this" does not support itself. |
This is wording copied over from the previous PR - how would you reword it instead? Explicit list of things that might escape? |
I updated the description around that sentence to include a more precise justification. |
Oddly, this means this compiles #[target_feature(enable = "avx2")]
fn bar() -> fn() {
|| avx2()
} but this does not #[target_feature(enable = "avx2")]
fn bar() -> fn() {
avx2
} That's not a blocker but might be worth an issue. (But changing this may mean we have to refine the safety condition.)
The definition of when something "live"s is subtle. I would make it about execution: you must guarantee that the target feature is available while the function or any closure defined inside that function executes. This is generally ensured because target features, once available, cannot usually be taken back; if you work in an environment where they can be taken back, it is your responsibility to ensure that no code inside a target feature function (including inside a closure) runs after this (until the feature is enabled again).
There is an enumeration saying that the attribute is allowed on main etc, only to then state that it is forbidden. This is confusing. Have we covered all special functions? |
This is indeed somewhat odd; refining the safety condition to cover also converting functions-you-could-call to safe fn pointers ought to be a minimal change (extending from "closure" to also cover "safe fn pointers generated inside the function", or something like that), and I think I'd be OK with leaving this as a follow-up, but I do not have strong opinions.
I reworded both sections to hopefully increase clarity, PTAL. |
Stabilization report
This is an updated version of #116114, which is itself a redo of #99767. Most of this commit and report were copied from those PRs. Thanks @LeSeulArtichaut and @calebzulawski!
Summary
Allows for safe functions to be marked with
#[target_feature]
attributes.Functions marked with
#[target_feature]
are generally considered as unsafe functions: they are unsafe to call, cannot be assigned to safe function pointers, and don't implement theFn*
traits.However, calling them from other
#[target_feature]
functions with a superset of features is safe.Test cases
Tests for this feature can be found in
tests/ui/target_feature/
.Edge cases
Closures
Closures defined inside functions marked with #[target_feature] inherit the target features of their parent function. They can still be assigned to safe function pointers and implement the appropriate
Fn*
traits.This means that in order to call a function with #[target_feature], you must guarantee that the target-feature is available while the function, and any closures defined inside it, execute.
Within a call to a
#[target_feature]
function, this is guaranteed recursively:#[target_feature]
function, it is guaranteed by the programmer through the safety requirements of the unsafe call.Note: this has an effect on existing code, as nowadays closures do not inherit features from the enclosing function, and thus this strengthens a safety requirement. It was originally proposed in #73631 to solve this by adding a new type of UB: “taking a target feature away from your process after having run code that uses that target feature is UB” .
This was motivated by userspace code already assuming in a few places that CPU features never disappear from a program during execution (see i.e. https://github.com/rust-lang/stdarch/blob/2e29bdf90832931ea499755bb4ad7a6b0809295a/crates/std_detect/src/detect/arch/x86.rs); however, concerns were raised in the context of the Linux kernel; thus, we propose to relax that requirement to "causing the set of usable features to be reduced is unsafe; when doing so, the programmer is required to ensure that no closures or safe fn pointers that use removed features are still in scope".
Closures accept
#[inline(always)]
, even within functions marked with#[target_feature]
. Since these attributes conflict,#[inline(always)]
wins out to maintain compatibility.ABI concerns
The ABI of some types can change when compiling a function with different target features. This could have introduced unsoundness with target_feature_11, but recent fixes (#133102, #132173) either make those situations invalid or make the ABI no longer dependent on features. Thus, those issues should no longer occur.
Special functions
The
#[target_feature]
attribute is forbidden from a variety of special functions, such as main, current and future lang items (e.g.#[start]
,#[panic_handler]
), and default trait implementations.This was not disallowed at the time of the first stabilization PR for target_features_11, and resulted in the following issues/PRs:
#[target_feature]
is allowed onmain
#108645#[target_feature]
is allowed on default implementations #108646#[target_feature]
on lang item functions #115910Documentation
target_feature_11
feature reference#1181cc tracking issue #69098
cc @workingjubilee
cc @RalfJung
r? @rust-lang/lang