Tracking issue for RFC 2045: improving `#[target_feature]`

[alexcrichton]

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

• Implement the proposed #[target_feature] semantics
• Document these semantics: Document target_feature and cfg_target_feature. reference#545
• Stabilize
  • x86_64 & i686
    • The basic set (sse–sse4.2, avx, avx2, ...) (Stabilize x86/x86_64 SIMD #49664)
    • adx: Stabilize ADX target feature #93745
    • avx512
    • mmx (never going to be stabilized)
    • sse4a
    • tbm
    • lahfsahf
    • prfchw
  • arm
  • aarch64
  • hexagon
  • powerpc
  • mips

@gnzlbg have anything else you want filled out here?

(below added from comments on PR)

• 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_feature and target_feature don't interact properly #42515
• resolve bug: repr(simd) is unsound #44367
• When should cfg(target_feature = "backchain") (s390x target feature) be enabled? #142412

[gnzlbg]

@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_feature and target_feature don't interact properly #42515
• resolve bug: repr(simd) is unsound #44367

It would be nice if those API breaking changes could be prioritized.

[retep998]

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.

[gnzlbg]

@retep998 cfg!(feature) does not require any unsafe code.

[retep998]

@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)].

[gnzlbg]

@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 write inline, but inline(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.

[newpavlov]

Any news on implementation status of --enable-features="feature0,feature1,..." proposed in the RFC?

[gnzlbg]

@newpavlov this is being discussed in issue 49658 . (note from pnkfelix: did this mean to say #49653 ?)