Code change:
<ins> // only-x86_64 #![feature(target_feature_11)] #[target_feature(enable = "avx")] fn foo() {} #[target_feature(enable = "avx")] unsafe fn foo_unsafe() {} fn call(f: impl Fn()) { f() } fn call_mut(f: impl FnMut()) { f() } fn call_once(f: impl FnOnce()) { f() } fn main() { call(foo); //~ ERROR expected a `std::ops::Fn<()>` closure, found `fn() {foo}` call_mut(foo); //~ ERROR expected a `std::ops::FnMut<()>` closure, found `fn() {foo}` call_once(foo); //~ ERROR expected a `std::ops::FnOnce<()>` closure, found `fn() {foo}` call(foo_unsafe); //~^ ERROR expected a `std::ops::Fn<()>` closure, found `unsafe fn() {foo_unsafe}` call_mut(foo_unsafe); //~^ ERROR expected a `std::ops::FnMut<()>` closure, found `unsafe fn() {foo_unsafe}` call_once(foo_unsafe); //~^ ERROR expected a `std::ops::FnOnce<()>` closure, found `unsafe fn() {foo_unsafe}` } </ins>

Related discussion:
text: (Moved from with an PoC.) The following program () demonstrates how current implementation of allows using a targetfeature from safe code without ensuring it's actually available: This is unsound because it allows executing (e.g.) AVX instructions on CPUs that do not implement them, which is UB. It only works because "safe fns with targetfeatures" are erroneously considered to implement the FnOnce/FnMut/Fn traits.
Proposed resolution: It would probably be better to add the to functions implicitly during lowering to HIR. Implicit is already to functions in 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.
Or perhaps the RFC should be revised to still require writing and only unsafety checker need to be enhanced to allow calling unsafe functions without unsafe blocks in the situations known to be safe. That would be even less magic, which is good, IMO. The ergonomic regression would be minor because would still be not required at call sites.
Good catch. Another option is that referencing, not calling, a target-feature function is unsafe, but I guess that is a bit inconsistent given that this already compiles (): In other words, accessing a safe target feature 1.1 function would be unsafe (unless the target feature is in scope), not just calling it. I think that this is what I would expect somehow, but I would expect it to apply uniformly to both safe and unsafe target feature functions (and that's not an option). The downside of this approach is that we don't know why the function was declared unsafe, not really -- was it only because of the target feature? Or were there additional requirements that would have made it unsafe?
For example, a whole bunch of functions take raw pointers and use them to access memory, so they need to be unsafe even if the respective target feature is enabled in the calling context.
The downside of this approach is that we don't know why the function was declared unsafe, not really -- was it only because of the target feature? Or were there additional requirements that would have made it unsafe? Ah, right, that's a good argument.