Tracking Issue for `naked_functions_target_feature`

[folkertdev]

The feature gate for the issue is #![feature(naked_functions_target_feature)].

The #[target_feature(enable = "...")] attribute on standard functions can have two effects:

1. change the ABI (e.g. how vector types are passed)
2. change what instructions are accepted in the body (e.g. whether vector instructions are allowed)

At the time of writing, target_feature is ignored when generating code for naked functions even with this feature enabled! Hence, you almost certainly don't need to enable this feature.

If you need to change what instructions are accepted, you can use assembler directives in the naked assembly. See #137720 for examples on how to do that on the most common platforms.

For naked functions, a target_feature does not change the generated code of that function: naked functions must already assume that their registers are in particular registers, and can document assumptions about e.g. the use of vector registers as safety conditions on the naked function itself. Hence, the target feature is useful only as documentation, and currently not strictly needed. Note that there are plans to it a hard requirement that functions using vector types in their signature enable the relevant target features.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Implement the RFC (cc @rust-lang/XXX -- can anyone write up mentoring
  instructions?)
• Adjust documentation (see instructions on rustc-dev-guide)
• Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• should we try to automatically handle target features at all?
• if so, how do we deal with platforms where LLVM has no tools for toggling target features from inline assembly (e.g. wasm simd128)
• and how do we deal with the complex interplay of target features with the (different versions of) the target platform (e.g. armv8 has very complex target features)

Implementation history

[folkertdev]

@rustbot label +A-naked +F-naked_functions