Consider `adt_const_params` for intrinsics

[nazar-pc]

Adjacent to #605, I'm wondering whether it'd be acceptable to use adt_const_params for intrinsics like atomics.

Then this signature:

fn atomic_i_increment<I: Integer, const SCOPE: u32, const SEMANTICS: u32>(
    ptr: &mut I,
) -> I

Will change to something like this:

fn atomic_i_increment<I: Integer, const SCOPE: Scope, const SEMANTICS: Semantics>(
    ptr: &mut I,
) -> I

And usage will be something like this:

atomic_i_increment::<_, { Scope::QueueFamily }, { Semantics::NONE }>(..)

[Firestar99]

I wish, but requiring nightly-only features breaks building spirv-std on stable, which breaks building it on docs.rs and using it as a dep within your CPU crates that may compile on stable. I'd be fine with having a feature in spirv-std that opts into using some nightly-only feature, but doing so here doesn't really seem possible without hiding the intrinsics completely on non-spirv targets, which will cause a bunch of problems if you plan your CPU crate to depend on your shader crate for type sharing.

[nazar-pc]

It would break using it on stable, but it will not break building it on docs.rs since docs.rs is already building things with nightly compiler.

I'm wondering if it even makes sense to expose those intrinsics on non-SPIR-V targets. If such restriction is added (now that it is possible to lint SPIR-V target with Clippy properly directly, etc.), spirv-std can expose or not expose things at compile time.

Thus nightly features will be enabled on nightly compiler (that compiling for SPIR-V target will require in the foreseeable future anyway) and they will not be on stable compiler.

---

Also regular standard library has some really weird things going on with intriniscs on other platforms, I suspect for backwards compatibility. For example, _mm_aeskeygenassist_si128 can be called both as _mm_aeskeygenassist_si128(reg, IMM8) and _mm_aeskeygenassist_si128::<IMM8>(reg) (and IntelliJ Rust plugin seems to be quite confused about it).

The source of this seems to be #[rustc_legacy_const_generics(1)] attribute, so maybe rust-gpu could provide a similar mechanism that achieves both ergonomic end-user behavior and satisfy the needs of knowing the value at compile time. Possibly even with some compiler shenanigans instead of technically requiring adt_const_params.

I'm just hoping there is a more ergonomic and misuse-resistant API for these.