Migrate to std::arch?

[gnzlbg]

std::arch::{x86, x86_64} provides:

• __cpuid_count
• __cpuid
• __get_cpuid_max
• has_cpuid

By using these instead of inline assembly or C code the library will work on stable and not require a C compiler.

[shepmaster]

will work on stable

Stable 1.27 and up, destroying any existing backwards compatibility.

I don't know if feature flags would work here either, as two libraries could choose each flag, resulting in duplicate definitions of everything...

Maybe something like how "no-std" is implemented. With all flags off, it uses the C backend. With the "std" flag (on by default) it uses the stdlib. I don't think you can "remove" dependencies based on a feature flag, however.

Another idea is build-script feature detection — if Rust 1.27, use the standard library, else use C. Similarly, I don't think this allows dependencies to be jettisoned.

Of course, one solution is to not worry about backwards compatibility. It's unlikely that there's many tools that are depending on this, and they can have multiple versions of Cupid in the dependency graph — I'd be shocked if someone used this and then re-exported it.

[gnzlbg]

Stable 1.27 and up, destroying any existing backwards compatibility.

I think it would be worth it to start by replacing the inline assembly pieces with std::arch, which has been available since January on nightly. Nightly can technically break the inline assembly anyways, so depending on how you look at it, that might not be a breaking change.

For stable I think the build.rs approach might be the lesser evil. Just detect the Rust version and use std::arch if it is >= 1.27, that allows you to make this a non-breaking change.