Skip to content

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

Description

@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

@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:

Activity

  1. added
    B-unstableBlocker: Implemented in the nightly compiler and unstable.
    T-libs-api[DEPRECATED; DO NOT USE]
    A-SIMDArea: SIMD (Single Instruction Multiple Data)
    on Sep 25, 2017
  2. gnzlbg commented on Sep 26, 2017

    @gnzlbg
    Contributor

    @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:

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

  3. retep998 commented on Sep 26, 2017

    @retep998
    Contributor

    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.

  4. gnzlbg commented on Sep 26, 2017

    @gnzlbg
    Contributor

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

  5. retep998 commented on Sep 26, 2017

    @retep998
    Contributor

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

  6. gnzlbg commented on Sep 26, 2017

    @gnzlbg
    Contributor

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

  7. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Sep 27, 2017
  8. newpavlov commented on Mar 6, 2018

    @newpavlov
    Contributor

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

  9. gnzlbg commented on Apr 4, 2018

    @gnzlbg
    Contributor

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

  10. alexcrichton commented on Apr 4, 2018

    @alexcrichton
    MemberAuthor

    #48556 has entered FCP which I believe will implicitly stabilize this attribute

  11. gnzlbg commented on Apr 4, 2018

    @gnzlbg
    Contributor

    So after the inline-always fix it looks like the only bug open still being tracked here is #42515 .

  12. gnzlbg commented on Apr 4, 2018

    @gnzlbg
    Contributor

    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:

  13. 99 remaining items

  14. added a commit that references this issue on Aug 18, 2025
  15. added a commit that references this issue on Jan 1, 2026
  16. added a commit that references this issue on Jan 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-SIMDArea: SIMD (Single Instruction Multiple Data)A-stabilityArea: `#[stable]`, `#[unstable]` etc.A-target-featureArea: Enabling/disabling target features like AVX, Neon, etc.B-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCI-libs-radarLibs issues that are tracked on the team's radar.S-tracking-design-concernsStatus: There are blocking design concerns.T-langRelevant to the language teamT-libs-api[DEPRECATED; DO NOT USE]

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions