RFC: link-time capabilities

Link-time capabilities are capabilities that are not exposed to codegen, but only set at link time. Importantly, changing link-time capabilities does not require a clean recompile, unlike the current spirv capabilities.

I good first experiment ground would likely be Large Integer polyfills, which I think they are better suited at link time. A really common use-case would likely be to emit one shader module with Int64 Capabilitiy enabled, and another with u32 polyfill for all u64 integers. So implementing this at link time would allow you to compile the shader crate only once and link it twice.

There's a few variants I could imagine to specify these link-time capabilities:

• per entry point in the #[spirv(capability(polyfill_u64))], mapping well with multimodule
• per shader crate using #![spirv(capability(polyfill_u64))] at root level, mapping well to single module
• some new system that allows specifying how entry points are grouped, potentially allowing entry points to be emitted in a variety of modules with different link-time capabilities. Maybe not with the first implementation.

Importantly, this should work well with rust features, so you can #[cfg_attr(feature = "u64_emulation", spirv(capability(polyfill_u64)))] and compile only the final shader crate twice, while reusing the remaining compiled crate tree.

I could also see a similar system being employed for usual spirv capabilities in the future, replacing the current pre-declaration of used features in spirv-builder. Similarly to the zombie system, you could attach an OpCapability to a certain instruction. If that instruction is linked into a shader module, add the OpCapability to it. But if it's unused, DCE will kill the instruction thus the capability.

This reverses how you'd enable code that depends on some capability: Currently, you'd declare the capability in spirv-builder and have a #[cfg(target_feature = "")] in your code. With link-time capabilities, you use a normal rust feature like #[cfg(feature = "")]to gate your code requiring some capability, and if the end user enables that feature, it implicitly enables the required capability. The final shader crate binary can itself have features enabled though spirv-builder, that enable features of any such library gating required capabilities like you'd normally do in Cargo.toml.

Start by reading the Large Integer polyfills issue (#307), then trace how spirv-builder currently declares capabilities and how the final shader crate is built. Compare the proposed per-entry-point, per-crate, and feature-gated approaches. Done would mean a decided design and an implementation plan for reusing compiled crates while linking variants with different capabilities.