Document the `target_feature_11` feature #1181

LeSeulArtichaut · 2022-03-17T22:02:11Z

joshtriplett · 2022-07-05T17:49:36Z

We talked about this in today's lang meeting. This looks good, and we should merge it as soon as we stabilize the feature.

…re-11, r=estebank Stabilize `#![feature(target_feature_11)]` ## Stabilization report ### Summary Allows for safe functions to be marked with `#[target_feature]` attributes. Functions marked with `#[target_feature]` are generally considered as unsafe functions: they are unsafe to call, cannot be assigned to safe function pointers, and don't implement the `Fn*` traits. However, calling them from other `#[target_feature]` functions with a superset of features is safe. ```rust // Demonstration function #[target_feature(enable = "avx2")] fn avx2() {} fn foo() { // Calling `avx2` here is unsafe, as we must ensure // that AVX is available first. unsafe { avx2(); } } #[target_feature(enable = "avx2")] fn bar() { // Calling `avx2` here is safe. avx2(); } ``` ### Test cases Tests for this feature can be found in [`src/test/ui/rfcs/rfc-2396-target_feature-11/`](https://github.com/rust-lang/rust/tree/b67ba9ba208ac918228a18321fc3a11a99b1c62b/src/test/ui/rfcs/rfc-2396-target_feature-11/). ### Edge cases - rust-lang#73631 Closures defined inside functions marked with `#[target_feature]` inherit the target features of their parent function. They can still be assigned to safe function pointers and implement the appropriate `Fn*` traits. ```rust #[target_feature(enable = "avx2")] fn qux() { let my_closure = || avx2(); // this call to `avx2` is safe let f: fn() = my_closure; } ``` This means that in order to call a function with `#[target_feature]`, you must show that the target-feature is available while the function executes *and* for as long as whatever may escape from that function lives. ### Documentation - Reference: rust-lang/reference#1181 --- cc tracking issue rust-lang#69098 r? `@ghost`

…re-11, r=estebank Stabilize `#![feature(target_feature_11)]` ## Stabilization report ### Summary Allows for safe functions to be marked with `#[target_feature]` attributes. Functions marked with `#[target_feature]` are generally considered as unsafe functions: they are unsafe to call, cannot be assigned to safe function pointers, and don't implement the `Fn*` traits. However, calling them from other `#[target_feature]` functions with a superset of features is safe. ```rust // Demonstration function #[target_feature(enable = "avx2")] fn avx2() {} fn foo() { // Calling `avx2` here is unsafe, as we must ensure // that AVX is available first. unsafe { avx2(); } } #[target_feature(enable = "avx2")] fn bar() { // Calling `avx2` here is safe. avx2(); } ``` ### Test cases Tests for this feature can be found in [`src/test/ui/rfcs/rfc-2396-target_feature-11/`](https://github.com/rust-lang/rust/tree/b67ba9ba208ac918228a18321fc3a11a99b1c62b/src/test/ui/rfcs/rfc-2396-target_feature-11/). ### Edge cases - rust-lang#73631 Closures defined inside functions marked with `#[target_feature]` inherit the target features of their parent function. They can still be assigned to safe function pointers and implement the appropriate `Fn*` traits. ```rust #[target_feature(enable = "avx2")] fn qux() { let my_closure = || avx2(); // this call to `avx2` is safe let f: fn() = my_closure; } ``` This means that in order to call a function with `#[target_feature]`, you must show that the target-feature is available while the function executes *and* for as long as whatever may escape from that function lives. ### Documentation - Reference: rust-lang/reference#1181 --- cc tracking issue rust-lang#69098 r? ``@ghost``

…-11, r=estebank Stabilize `#![feature(target_feature_11)]` ## Stabilization report ### Summary Allows for safe functions to be marked with `#[target_feature]` attributes. Functions marked with `#[target_feature]` are generally considered as unsafe functions: they are unsafe to call, cannot be assigned to safe function pointers, and don't implement the `Fn*` traits. However, calling them from other `#[target_feature]` functions with a superset of features is safe. ```rust // Demonstration function #[target_feature(enable = "avx2")] fn avx2() {} fn foo() { // Calling `avx2` here is unsafe, as we must ensure // that AVX is available first. unsafe { avx2(); } } #[target_feature(enable = "avx2")] fn bar() { // Calling `avx2` here is safe. avx2(); } ``` ### Test cases Tests for this feature can be found in [`src/test/ui/rfcs/rfc-2396-target_feature-11/`](https://github.com/rust-lang/rust/tree/b67ba9ba208ac918228a18321fc3a11a99b1c62b/src/test/ui/rfcs/rfc-2396-target_feature-11/). ### Edge cases - rust-lang#73631 Closures defined inside functions marked with `#[target_feature]` inherit the target features of their parent function. They can still be assigned to safe function pointers and implement the appropriate `Fn*` traits. ```rust #[target_feature(enable = "avx2")] fn qux() { let my_closure = || avx2(); // this call to `avx2` is safe let f: fn() = my_closure; } ``` This means that in order to call a function with `#[target_feature]`, you must show that the target-feature is available while the function executes *and* for as long as whatever may escape from that function lives. ### Documentation - Reference: rust-lang/reference#1181 --- cc tracking issue rust-lang#69098 r? `@ghost`

src/attributes/codegen.md

ehuss · 2023-02-28T17:44:36Z

src/attributes/codegen.md

+For this reason, a function marked with `target_feature` is unsafe, except in
+a context that supports the given features. For example:


This doesn't really define what "a context that supports the given features" means. Can you add a little more detail here? For example, the RFC seems to contain more well-defined text as to exactly what this means. I'd like this to be able to address:

The context means functions that have at least the exact same target_features enabled.

This does not include implied features (that is, a fn with sse2 can't call a function with sse, even though sse2 implicitly enabled sse).

This does not include features enabled by default on the platform, or manually enabled as compiler flags.

Also include a short discussion of what is or is not allowed with trait definitions and impls.

…tebank Stabilize `#![feature(target_feature_11)]` ## Stabilization report ### Summary Allows for safe functions to be marked with `#[target_feature]` attributes. Functions marked with `#[target_feature]` are generally considered as unsafe functions: they are unsafe to call, cannot be assigned to safe function pointers, and don't implement the `Fn*` traits. However, calling them from other `#[target_feature]` functions with a superset of features is safe. ```rust // Demonstration function #[target_feature(enable = "avx2")] fn avx2() {} fn foo() { // Calling `avx2` here is unsafe, as we must ensure // that AVX is available first. unsafe { avx2(); } } #[target_feature(enable = "avx2")] fn bar() { // Calling `avx2` here is safe. avx2(); } ``` ### Test cases Tests for this feature can be found in [`src/test/ui/rfcs/rfc-2396-target_feature-11/`](https://github.com/rust-lang/rust/tree/b67ba9ba208ac918228a18321fc3a11a99b1c62b/src/test/ui/rfcs/rfc-2396-target_feature-11/). ### Edge cases - rust-lang/rust#73631 Closures defined inside functions marked with `#[target_feature]` inherit the target features of their parent function. They can still be assigned to safe function pointers and implement the appropriate `Fn*` traits. ```rust #[target_feature(enable = "avx2")] fn qux() { let my_closure = || avx2(); // this call to `avx2` is safe let f: fn() = my_closure; } ``` This means that in order to call a function with `#[target_feature]`, you must show that the target-feature is available while the function executes *and* for as long as whatever may escape from that function lives. ### Documentation - Reference: rust-lang/reference#1181 --- cc tracking issue #69098 r? `@ghost`

ehuss · 2023-03-14T19:32:36Z

It looks like there are some changes in the implementation recently. Should those be reflected in the documentation here? For example:

Forbid the use of #[target_feature] on main rust#108651 — It might not hurt to explicitly mention that it is not allowed on main.
Forbid #[target_feature] on safe default implementations rust#108983 — I'm not sure, but I don't think there is anything to add here? My only thought is that the current wording of "safe trait method implementations" is maybe ambiguous, since default trait methods aren't normally called an "implementation" (usually I would reserve that for impl).

Is there anything I missed?

…tebank Stabilize `#![feature(target_feature_11)]` ## Stabilization report ### Summary Allows for safe functions to be marked with `#[target_feature]` attributes. Functions marked with `#[target_feature]` are generally considered as unsafe functions: they are unsafe to call, cannot be assigned to safe function pointers, and don't implement the `Fn*` traits. However, calling them from other `#[target_feature]` functions with a superset of features is safe. ```rust // Demonstration function #[target_feature(enable = "avx2")] fn avx2() {} fn foo() { // Calling `avx2` here is unsafe, as we must ensure // that AVX is available first. unsafe { avx2(); } } #[target_feature(enable = "avx2")] fn bar() { // Calling `avx2` here is safe. avx2(); } ``` ### Test cases Tests for this feature can be found in [`src/test/ui/rfcs/rfc-2396-target_feature-11/`](https://github.com/rust-lang/rust/tree/b67ba9ba208ac918228a18321fc3a11a99b1c62b/src/test/ui/rfcs/rfc-2396-target_feature-11/). ### Edge cases - rust-lang/rust#73631 Closures defined inside functions marked with `#[target_feature]` inherit the target features of their parent function. They can still be assigned to safe function pointers and implement the appropriate `Fn*` traits. ```rust #[target_feature(enable = "avx2")] fn qux() { let my_closure = || avx2(); // this call to `avx2` is safe let f: fn() = my_closure; } ``` This means that in order to call a function with `#[target_feature]`, you must show that the target-feature is available while the function executes *and* for as long as whatever may escape from that function lives. ### Documentation - Reference: rust-lang/reference#1181 --- cc tracking issue #69098 r? `@ghost`

traviscross · 2024-09-03T20:49:46Z

In discussing this today, we note the recent related work here:

Emit future-incompatibility lint when calling/declaring functions with vectors that require missing target feature rust#127731

LeSeulArtichaut mentioned this pull request Mar 17, 2022

Tracking issue for target_feature 1.1 RFC rust-lang/rust#69098

Open

10 tasks

Document the target_feature_11 feature

54107ec

LeSeulArtichaut force-pushed the target-feature-11 branch from a9dff82 to 54107ec Compare March 17, 2022 22:09

ehuss added the S-waiting-on-stabilization Waiting for a stabilization PR to be merged in the main Rust repository label Apr 9, 2022

joshtriplett added I-lang-nominated and removed I-lang-nominated labels Jun 29, 2022

LeSeulArtichaut mentioned this pull request Aug 5, 2022

Stabilize #![feature(target_feature_11)] rust-lang/rust#99767

Merged

ehuss reviewed Feb 28, 2023

View reviewed changes

Address review comments

d00e6bb

calebzulawski mentioned this pull request Sep 24, 2023

Stabilize target_feature_11 rust-lang/rust#116114

Open

traviscross mentioned this pull request Sep 3, 2024

Emit future-incompatibility lint when calling/declaring functions with vectors that require missing target feature rust-lang/rust#127731

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Document the `target_feature_11` feature #1181

Document the `target_feature_11` feature #1181

LeSeulArtichaut commented Mar 17, 2022

joshtriplett commented Jul 5, 2022

ehuss Feb 28, 2023

ehuss commented Mar 14, 2023

traviscross commented Sep 3, 2024

		For this reason, a function marked with `target_feature` is unsafe, except in
		a context that supports the given features. For example:

Document the target_feature_11 feature #1181

Are you sure you want to change the base?

Document the target_feature_11 feature #1181

Conversation

LeSeulArtichaut commented Mar 17, 2022

joshtriplett commented Jul 5, 2022

ehuss Feb 28, 2023

Choose a reason for hiding this comment

ehuss commented Mar 14, 2023

traviscross commented Sep 3, 2024

Document the `target_feature_11` feature #1181

Document the `target_feature_11` feature #1181