Pre-RFC: stabilization of target_feature

[gnzlbg]

@pedrocr you wrote:

@pedrocr

But based on the discussion above here's an integrated proposal:

Compile time detection is done with target_feature like this:

if cfg!(target_feature = "some feature") { ... code with feature ... } else { ... code without ... }

This is clear, if cfg!(target_feature = "some feature") { is a macro that expands at compile-time to either true or false. This enables conditional code generation. Here the question of whether the compiler can hoist target specific instructions out of the if remains open. The compiler shouldn't do this. Has the same semantics as cfg!(target_feature = "some feature") in the RFC.

@pedrocr

Runtime detection is done the same way:

if cfg!(runtime_target_feature = "some feature") { ... code with feature ... } else { ... code without ... }

IIUC this macro expands to some runtime cpuid code, but it doesn't have any semantics beyond that right? That is, the value of cfg!(target_feature) in both branches is the same. Is this correct? Also, you can call whatever code you like in both branches, nothing is checked at compile-time, at worst you get a segfault. Is this correct? This is basically the same as calling a function from an external crate, like in the cpuid examples of the RFC.

@pedrocr

Unconditional feature enablement is also supported but is unsafe. This is your current target_feature and should be a corner case most people will never use.

#[unconditional_target_feature("some feature")] fn myfunc() { ... code with feature ... }

This has the same semantics of #[target_feature] in the RFC.

So IIUC the only change you want is for some sort of run-time detection to be added to the RFC, whether it happens via cfg!(runtime_target_feature = "feature") or std::cpu::has_feature("feature") is just a minor syntactic detail right?