RFC: link-time capabilities

先閱讀 Large Integer polyfills issue (#307)，然後追蹤 spirv-builder 目前如何宣告 capabilities，以及最終的 shader crate 如何建置。比較依 entry point、依 crate 以及 feature-gated 的方案。完成的標準是確定一種設計，並制定一份實作計畫，以便重複使用已編譯的 crate，同時連結具有不同 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.