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.

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

[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 ?)