Tracking issue for target_feature 1.1 RFC

[nikomatsakis]

View all comments

This is a tracking issue for the RFC "target_feature 1.1" (rust-lang/rfcs#2396).

Issues: F-target_feature_11 target feature 1.1 RFC

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_11 feature 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 on main #108645
  • #[target_feature] is allowed on default implementations #108646
  • target_feature_11 rejects code that was previously accepted #108655
  • The extern "C" ABI of SIMD vector types depends on target features (tracking issue for abi_unsupported_vector_types future-incompatibility lint) #116558
  • The (stable) neon aarch64 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 the Fn traits.
• target-feature 1.1: should closures inherit target-feature annotations? #73631 -- behavior of closures and target-features

[LeSeulArtichaut]

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]

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]

It would probably be better to add the unsafe to #[target_feature] functions implicitly during lowering to HIR.
Implicit unsafe is already added to functions in extern blocks 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.

[LeSeulArtichaut]

Now that #69274 landed, I think we can check Implement the RFC 🙂

[LeSeulArtichaut]

@rustbot release-assignment