Repository navigation
Tracking issue for target_feature 1.1 RFC #69098
Description
This is a tracking issue for the RFC "target_feature 1.1" (rust-lang/rfcs#2396).
Issues:
F-target_feature_11
People
Last updated in Mar 2023:
- Shepherd:
gnzlbg@workingjubilee (person who can help answer tricky questions that arise during implementation) - Lang team liaison: @joshtriplett (main point of contact from lang team)
Step
- Implement the RFC: Implement RFC 2396:
#[target_feature]1.1 #69274 - Adjust documentation: Document the
target_feature_11feature reference#1181 - Stabilization PR (see instructions on rustc-guide)
- Revert? Revert stabilization of
#![feature(target_feature_11)]#108654 - I suppose we're off the end of the script, here. Bugs to fix:
-
#[target_feature]is allowed onmain#108645 -
#[target_feature]is allowed on default implementations #108646 -
target_feature_11rejects code that was previously accepted #108655 - The
extern "C"ABI of SIMD vector types depends on target features (tracking issue forabi_unsupported_vector_typesfuture-incompatibility lint) #116558 - The (stable)
neonaarch64 target feature is unsound: it changes the float ABI #131058
-
- Re-stabilization PR: Stabilize target_feature_11 #134090
Unresolved questions
target_feature_11 allows bypassing safety checks through Fn* traits #72012 -- soundness hole where safe target-feature functions implement theFntraits.target-feature 1.1: should closures inherit target-feature annotations? #73631 -- behavior of closures and target-features
Activity
LeSeulArtichaut commentedon Feb 18, 2020
I've been working on this, trying to see if I would be able to implement this with my very little knowledge of the compiler. I think I can propose a PR soon.
@rustbot claim
hanna-kruppe commentedon May 2, 2020
In #69274 (comment), @petrochenkov pointed out a complication not made clear in the RFC (nor realized by anyone during the original discussion, AFAICT): safe trait functions are explicitly excluded because we can't check all call sites, but function items implement the
Fn*traits, so safe functions with target features enabled face a similar problem. That is, unless they are special-cased in some way that results in them not implementing those traits.petrochenkov commentedon May 2, 2020
It would probably be better to add the
unsafeto#[target_feature]functions implicitly during lowering to HIR.Implicit
unsafeis already added to functions inexternblocks in the same way.That would make the unsafety checker the only place (besides AST lowering) where they would be treated specially. Like, "yes, the function is unsafe, but we know that it's safe to call in this specific context, so the unsafe block can be omitted".
The special coercion checks would no longer be necessary in that case.
Rollup merge of rust-lang#69274 - LeSeulArtichaut:target-feature-11, …
Auto merge of rust-lang#69274 - LeSeulArtichaut:target-feature-11, r=…
LeSeulArtichaut commentedon May 3, 2020
Now that #69274 landed, I think we can check
Implement the RFC🙂LeSeulArtichaut commentedon May 3, 2020
@rustbot release-assignment
hanna-kruppe commentedon May 8, 2020
Filed #72012 for the unsoundness discussed above (I think this is how T-lang tracking issues are supposed to be used now).
nikomatsakis commentedon Jun 22, 2020
Opened #73631 to discuss the expected behavior of closures with target-feature.
44 remaining items
calebzulawski commentedon Nov 24, 2024
This looks like it would trigger it. While not directly related to this topic, I see you are passing the closure via
Fn--I've run into issues passing closures viaFn*traits in the past (#96929)briansmith commentedon Nov 24, 2024
calebzulawski commentedon Nov 24, 2024
RalfJung commentedon Nov 25, 2024
It's a work-around for an LLVM bug. In an ideal world we wouldn't have to worry about this.
Strictly speaking this doesn't make sense either. LLVM "just" has to ensure that the operations from
fare not hoisted out of any conditionals or loops ing. But LLVM isn't able to represent that, so instead it just stops inlining altogether. Which then puts us into a pickle regardinginline(always)(even ignoring the bug): the user requested to be always inlined, but we can't actually make that happen if the function has target features. What do we do?The status quo is that:
inline(always)then we don't inheritIt's not pretty, but between that long-standing LLVM bug and the general LLVM limitation around inlining and target features, and given our backwards compatibility constraints, it is unclear how to do better.
Compared to stable, with TF 1.1 nothing changes for the behavior of
inline(always)functions or closures. What does change is the behavior of non-inline(always)closures in atarget_featurefunction.Rollup merge of rust-lang#134090 - veluca93:stable-tf11, r=oli-obk
Rollup merge of rust-lang#134090 - veluca93:stable-tf11, r=oli-obk
Rollup merge of rust-lang#134090 - veluca93:stable-tf11, r=oli-obk
Unrolled build for rust-lang#134090
Rollup merge of #134090 - veluca93:stable-tf11, r=oli-obk
Rollup merge of #134090 - veluca93:stable-tf11, r=oli-obk
Rollup merge of rust-lang#134090 - veluca93:stable-tf11, r=oli-obk
Rollup merge of rust-lang#134090 - veluca93:stable-tf11, r=oli-obk
SabrinaJewson commentedon Sep 11, 2025
Should this issue be closed?
folkertdev commentedon Jul 1, 2026
Probably, this has been stable since 1.86, the stabilization PR is #134090.