This issue constitutes the stabilisation report as per the rustc dev guide. Tracking issue: #44839
This came about as a result of the discussion on stabilising the aarch64 runtime feature detection macro: #86941
Stabilisation PR: #90621
Summary
Along with std::is_aarch64_feature_detected!, we'd like to stabilise aarch64_target_feature. This allows using the target_feature attribute on aarch64 platforms like such:
#[target_feature(enable = "neon")]
unsafe fn asimd_code() {
...
This allows for unconditional code generation - the above function will be compiled as if assumed to only run on hosts that support the neon feature.
Note that this differs from compile-time feature detection (via cfg!) and run-time feature detection (via the std::is_aarch64_feature_detected! macro).
Test cases
There are a variety of x86_64 tests in place testing the behaviour of the target_feature attribute. Since this proposal does not change the behaviour of target_feature, only stabilises some of its inputs, I do not believe there's any pressing need to update these tests.
Documentation
I've updated the Rust reference: rust-lang/reference#1102
Unresolved questions
It's possible in the future that PAuth will have reason to be split into two separate features (paca and pacg in Linux's AT_HWCAP. If this happens the plan would be to add two new target_feature options and, if necessary, keep PAuth as the combination of the two. It doesn't make sense to pre-emptively separate them before they're separate in LLVM, nor keep PAuth unstable for an undetermined amount of time.
This issue constitutes the stabilisation report as per the rustc dev guide. Tracking issue: #44839
This came about as a result of the discussion on stabilising the aarch64 runtime feature detection macro: #86941
Stabilisation PR: #90621
Summary
Along with
std::is_aarch64_feature_detected!, we'd like to stabiliseaarch64_target_feature. This allows using thetarget_featureattribute on aarch64 platforms like such:This allows for unconditional code generation - the above function will be compiled as if assumed to only run on hosts that support the
neonfeature.Note that this differs from compile-time feature detection (via
cfg!) and run-time feature detection (via thestd::is_aarch64_feature_detected!macro).Test cases
There are a variety of x86_64 tests in place testing the behaviour of the
target_featureattribute. Since this proposal does not change the behaviour oftarget_feature, only stabilises some of its inputs, I do not believe there's any pressing need to update these tests.Documentation
I've updated the Rust reference: rust-lang/reference#1102
Unresolved questions
It's possible in the future that
PAuthwill have reason to be split into two separate features (pacaandpacgin Linux'sAT_HWCAP. If this happens the plan would be to add two newtarget_featureoptions and, if necessary, keep PAuth as the combination of the two. It doesn't make sense to pre-emptively separate them before they're separate in LLVM, nor keepPAuthunstable for an undetermined amount of time.