spirv-std-nightly crate to enable adt_const_params use

[Firestar99]

Counterproposal to @nazar-pc's PR #635

PR #635 is modifying spirv-std to use adt_const_params, which would break for anyone using a CPU-GPU shared crate that depends on spirv-std where the CPU target is compiled with stable. It would also be a significant breaking change, with any crate using those functions needing to be manually migrated.

This PR introduces the new crate spirv-std-nightly, which reexports the entirety of spirv-std, but replaces individual functions with const-generic replacements. It should thus be equivalent to PR #635 but not break any existing setups. Instead, it's a drop-in replacement with a simple use spirv_std_nightly as spirv_std in any crate. (Though any crate doing so will obviously no longer compile on stable.) You can also mix and match both spirv-std crates and it should work just fine.

Note on publishing: Our release-plz setup can only update existing crates, I'd need to claim the name and do some setup before we release. But I first want to know if we're claiming that name or if we want to rename the crate beforehand.

close #607
close #414

[nazar-pc]

That is a creative workaround, but I guess better than not supporting stable at all

[nazar-pc]

The biggest question I have about this is the name. Const generics is one thing, but maybe there will be other nightly features that would be beneficial, then current naming will not scale. Maybe -nightly or -experimental suffix would be more fitting?

[LegNeato]

Can't we just gate code to nightlies with the feature we need? I think serde does something similar...they turn on and off code on different channels and different versions

[nazar-pc]

Possible, but then these APIs will have to go into the submodule or something. Right now it is more like "this is what some future version of spirv-std will look like".

[Firestar99]

EDIT: fixed

Rebased it on main and renamed the crate to spirv-std-nightly, only to notice it broke.
(old functioning rev ecc6db6 in case you need it)

The bitflags v2 update in #637 broke this PR. In bitflags v1 we had Semantics(u32) but bitflags v2 does Semantics(SemanticsBits(u32)) and our derive is only attached to the outer one. Bytemuck's traits solve this via the bitflags/bytemuck feature deriving Pod on the inner type, which is why you also need to derive it on the outer type to get it functioning. So we'd need to convince bitflags to have a nightly-adt-const-params feature of some sort to support this.

[nazar-pc]

Hm... how important is it to depend on bitflags in the first place? Looks like we're fighting their design decisions and it might be easier to simply write necessary implementation manually in the way rust-gpu needs it. Macro expansion could be the starting point.

[Firestar99]

Bitflags is the standard crate for bitflags, wouldn't really want to replace it. Also I think there's a decent chance they'd take a PR adding that behind a feature gate.

[nazar-pc]

That is just perfect derive issue. Simply replace derive with impl core::marker::ConstParamTy_ for T { } and it'll work. It is unfortunate that the trait name is for some reason different, but that is exactly what the nightly derive expands to today.

UPD: Hm... maybe not. I really don't like fight external crates for simple things 😕

[Firestar99]

Found a workaround: The bitflags! macro supports not just pub struct Semantics but also impl Semantics to allow you to define the struct yourself.