Tracking issue for target_feature 1.1 RFC #69098
Comments
nikomatsakis
added
B-RFC-approved
|
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 |
|
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 |
|
It would probably be better to add the 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. |
…r=hanna-kruppe Implement RFC 2396: `#[target_feature]` 1.1 Tracking issue: rust-lang#69098 r? @nikomatsakis cc @gnzlbg @joshtriplett
…hanna-kruppe Implement RFC 2396: `#[target_feature]` 1.1 Tracking issue: rust-lang#69098 r? @nikomatsakis cc @gnzlbg @joshtriplett
|
Now that #69274 landed, I think we can check |
|
@rustbot release-assignment |
|
Filed #72012 for the unsoundness discussed above (I think this is how T-lang tracking issues are supposed to be used now). |
|
Opened #73631 to discuss the expected behavior of closures with target-feature. |
LeSeulArtichaut
added
B-RFC-implemented
|
It looks like there haven't been any updates on this in a while--is there anything I can do to bring this closer to stabilization? |
|
@calebzulawski I know it's almost a year later but I think this is probably ready for a stabilization report? (cc @rust-lang/lang) |
|
Tried to help by opening rust-lang/reference#1181, feedback from people who actually know what they are doing would be greatly appreciated. While writing the PR, I noticed that #72012 is a breaking change for wasm targets, where fn call_it(f: impl FnOnce()) {}
#[target_feature(enable = "simd128")]
fn foo_simd128() {}
fn main() {
foo_simd128(); // OK
call_it(foo_simd128); // error: the trait `FnOnce<()>` is not implemented
} |
joshtriplett
added
the
S-tracking-ready-to-stabilize
…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`
…iler-errors Revert stabilization of `#![feature(target_feature_11)]` This reverts rust-lang#99767 due to the presence of bugs rust-lang#108645 and rust-lang#108646. cc `@joshtriplett` cc tracking issue rust-lang#69098 r? `@ghost`
|
An edge case is introduced by the current implementation where old code is now rejected due to the interaction with I intend to do some work on how target features operate and will look into addressing this regression. |
|
Ideally the diagnostics should also be improved. I wouldn't say it's a hard stabilization blocker but it would be nice to have: #108680 |
workingjubilee
added
the
A-target-feature
|
I had taken a look at #108680 several months ago and I couldn't figure out a straightforward way to plumb the available features for the diagnostic. I agree that it's probably not worth holding up the entire feature. I checked the F-target_feature_11 label and don't see any new/remaining issues, so I think it should be fine? I opened a new stabilization PR in #116114. |
|
@calebzulawski the plumbing part has been addressed in #109710 . The reasons why the PR is stalled were not due to the plumbing. |
|
The internal compiler name for this is rather confusing: |
|
This is currently blocked on #116558: even calling a function with fewer target features can be UB since target features affect the ABI of some types. rust-lang/lang-team#235 proposes a design meeting on how we could resolve that. |
|
#131058 is another potential blocker -- this code is unsound on an aarch64-softfloat target: #[target_feature(enable = "neon")]
pub fn square(num: f32) -> f32 {
num * num
}
fn main() {
if is_aarch64_feature_detected!("neon") {
// The argument will be passed in general-purpose registers,
// but the callee expects the argument in a float register.
println!("{}", unsafe { square(42.0) });
}
} |
This is a tracking issue for the RFC "target_feature 1.1" (rust-lang/rfcs#2396).
Issues: F-target_feature_11target feature 1.1 RFC
People
Last updated in Mar 2023:
gnzlbg@workingjubilee (person who can help answer tricky questions that arise during implementation)Step
#[target_feature]1.1 #69274target_feature_11feature reference#1181#![feature(target_feature_11)]#108654#[target_feature]is allowed onmain#108645#[target_feature]is allowed on default implementations #108646target_feature_11rejects code that was previously accepted #108655extern "C"ABI of SIMD vector types depends on target features (tracking issue forabi_unsupported_vector_typesfuture-incompatibility lint) #116558neonaarch64 target feature is unsound: it changes the float ABI #131058Unresolved 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-featuresThe text was updated successfully, but these errors were encountered: