Repository navigation
Tracking issue for RFC 2045: improving #[target_feature] #44839
Description
Activity
- addedB-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.T-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]A-SIMDArea: SIMD (Single Instruction Multiple Data)Area: SIMD (Single Instruction Multiple Data)
on Sep 25, 2017 @alexchrichton
Yes, we should also clear some of the unresolved questions:
- consensus on the API for run-time feature detection
- should
cfg!(feature)work across #[inline(always)] functions, generics, etc?
And some related tasks:
- API breaking change: allow
#[target_feature]on unsafe functions only - API breaking change:
#[target_feature = "+feature"]=>#[target_feature(enable = "feature")] - fix bug:
cfg_target_featureandtarget_featuredon't interact properly #42515 - resolve bug: repr(simd) is unsound #44367
It would be nice if those API breaking changes could be prioritized.
Rust already will sometimes not inline a
#[inline(always)]function (notably recursive situations), so unsafe code already can't assume that#[inline(always)]code will always be inlined.@retep998
cfg!(feature)does not require any unsafe code.@gnzlbg I meant in regards to where the RFC states that
#[target_feature]and#[inline(always)]mixed together should result in an error. We can simply not inline functions in that case, even if they are marked as#[inline(always)], because Rust will already sometimes not inline functions marked#[inline(always)].@retep998 We could definitely relax this by just not inlining an
#[inline(always)]function. I don't know if we want to do so: the user did not writeinline, butinline(always), we should at least warn here.What we cannot currently do is inlining a function across mismatching features (independently of its inlining annotations). The alternative sections of the RFC explores this a bit though.
- addedC-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFC
on Sep 27, 2017 Any news on implementation status of
--enable-features="feature0,feature1,..."proposed in the RFC?@newpavlov this is being discussed in
issue 49658. (note from pnkfelix: did this mean to say #49653 ?)#48556 has entered FCP which I believe will implicitly stabilize this attribute
So after the inline-always fix it looks like the only bug open still being tracked here is #42515 .
That bug looks hard to solve and probably won't make it before stabilization.
The following issues look "easy" to fix low-hanging fruit. It might be worth to fix these before stabilization:
99 remaining items
- added a commit that references this issue
on Dec 21, 2025 This tracking issue is tracking too many things at once. #150264 introduces separate tracking issues for each feature gate:
- Tracking Issue for aarch64_unstable_target_feature #150244
- Tracking Issue for aarch64_ver_target_feature #150245
- Tracking Issue for arm_target_feature #150246
- Tracking Issue for bpf_target_feature #150247
- Tracking Issue for csky_target_feature #150248
- Tracking Issue for ermsb_target_feature #150249
- Tracking Issue for hexagon_target_feature #150250
- Tracking Issue for lahfsahf_target_feature #150251
- Tracking Issue for loongarch_target_feature #150252
- Tracking Issue for mips_target_feature #150253
- Tracking Issue for nvptx_target_feature #150254
- Tracking Issue for powerpc_target_feature #150255
- Tracking Issue for prfchw_target_feature #150256
- Tracking Issue for riscv_target_feature #150257
- Tracking Issue for rtm_target_feature #150258
- Tracking Issue for s390x_target_feature #150259
- Tracking Issue for wasm_target_feature #150260
- Tracking Issue for x87_target_feature #150261
- added a commit that references this issue
on Dec 29, 2025 - added a commit that references this issue
on Feb 3, 2026 - added 4 commits that reference this issue
on May 22, 2026
This is a tracking issue for the
#[target_feature]segment of RFC 2045 (rust-lang/rfcs#2045).#[cfg(target_feature)]was tracked in #29717 and has since been stabilized.This tracks the following feature gates: aarch64_unstable_target_feature, aarch64_ver_target_feature, arm_target_feature, bpf_target_feature, csky_target_feature, ermsb_target_feature, hexagon_target_feature, lahfsahf_target_feature, loongarch_target_feature, mips_target_feature, powerpc_target_feature, prfchw_target_feature, riscv_target_feature, rtm_target_feature, s390x_target_feature, sse4a_target_feature, tbm_target_feature, wasm_target_feature, x87_target_feature.
Steps
#[target_feature]semanticstarget_featureandcfg_target_feature. reference#545mmx(never going to be stabilized)@gnzlbg have anything else you want filled out here?
(below added from comments on PR)
cfg!(feature)work across #[inline(always)] functions, generics, etc?And some related tasks:
#[target_feature]on unsafe functions only#[target_feature = "+feature"]=>#[target_feature(enable = "feature")]cfg_target_featureandtarget_featuredon't interact properly #42515cfg(target_feature = "backchain")(s390x target feature) be enabled? #142412