Given the following code:
#![feature(target_feature_11)]
#[target_feature(enable = "sse2", enable = "avx", enable = "sse")]
pub fn foo() {}
#[target_feature(enable = "sse")]
fn bar() {
foo();
}
The current output is:
error[E0133]: call to function with `#[target_feature]` is unsafe and requires unsafe function or block
--> src/main.rs:8:5
|
8 | foo();
| ^^^^^ call to function with `#[target_feature]`
|
= note: can only be called if the required target features are available
The note is easy to be misinterpreted: the function can also be called if the target features are not available, but it requires an unsafe annotation.
I think it would be nice for the note to list the missing target features. In this case, this would be sse2 and avx.
If one or more of the missing target features are enabled in the current build config, like via -C target-feature or -C target-cpu, or because the default is just that, then it should acknowledge this situation and explain that a #[target_feature] is still required.
So I'd imagine something like:
error[E0133]: call to function with `#[target_feature]` is unsafe and requires unsafe function or block
--> src/main.rs:8:5
|
8 | foo();
| ^^^^^ call to function with `#[target_feature]`
|
= help: in order for the call to be safe, the context requires the following additional target features: sse2, avx
= note: the sse2 target feature being enabled in the build configuration does not remove the requirement to list it in `#[target_feature]`
TLDR: I ask for two things:
- removing the
note in the general case (I think what it contains is already said in the main error msg), but if there are missing target features that are enabled in the build configuration, emit a note to point out that even though they are enabled, this has no influence on #[target_feature] (it's two different systems; see my example for the proposed wording)
- adding a
help that lists the missing target features (ideally if too many like more than 5 are missing, then cut the list to keep the error message short ("avx, sse2, sse, aes, foobar, and 3 more"))
cc #69098
@rustbot label A-diagnostics F-target_feature_11
Given the following code:
The current output is:
The note is easy to be misinterpreted: the function can also be called if the target features are not available, but it requires an
unsafeannotation.I think it would be nice for the note to list the missing target features. In this case, this would be
sse2andavx.If one or more of the missing target features are enabled in the current build config, like via
-C target-featureor-C target-cpu, or because the default is just that, then it should acknowledge this situation and explain that a#[target_feature]is still required.So I'd imagine something like:
TLDR: I ask for two things:
notein the general case (I think what it contains is already said in the main error msg), but if there are missing target features that are enabled in the build configuration, emit a note to point out that even though they are enabled, this has no influence on#[target_feature](it's two different systems; see my example for the proposed wording)helpthat lists the missing target features (ideally if too many like more than 5 are missing, then cut the list to keep the error message short ("avx, sse2, sse, aes, foobar, and 3 more"))cc #69098
@rustbot label A-diagnostics F-target_feature_11