Add GL_EXT_spirv_intrinsics_variadic extension

[rdb]

This is the first half of #331, adding the extension text for the variadics part (the forthcoming string extension is designed to be independent). I've also got a working implementation in glslang, which I will submit separately.

The extension adds variadic syntax (like void f(int x, ...)) for spirv_instruction functions, motivated by use cases like debugPrintfEXT and abortEXT. The grammar is written to restrict the use of the ellipsis to only spirv_instruction-qualified functions, though I expect most implementations will reject invalid uses semantically rather than purely at the grammar level.

I had underestimated how much work there was to define variadic functions properly, especially regarding overload resolution, which in practice won't come up much but must be addressed. The crux of it is this:

GLSL short-circuits function resolution: if there's an exact type match between the formal parameters and the calling arguments, that match is used and overload resolution is pre-empted. I've kept that rule intact by excluding variadic declarations from ever being considered an "exact match", so any call involving a variadic always goes through normal overload resolution. As it happens, glslang's existing variadics support (used only for builtins) already behaves this way.

Where I deliberately deviate from the current glslang behavior is that glslang currently reports f(float) and f(float, ...) as ambiguous when called with f(1) but chooses the former silently with f(1.0) as per the exact-match rule, which I deemed too surprising. I have resolved this by adding a tie-break rule making it prefer the non-variadic overload in this specific case. The alternatives all turned out messy; the cleanest would require effectively redefining function calling in GLSL by gutting the exact-match rule, which I deemed to be far too invasive for an extension of this kind. Issue 5 lays out the arguments in more detail; the chosen option does have a pleasing analogy in C++.

Another point of note is that I made this against 4.60.8 since I could not locate a copy of the 4.60.7 spec that the base extension is based on. I can submit a PR to update the base extension or verify my extension against a copy of the 4.60.7 spec if someone can point me to one, if this is considered a problem.

This is my first time submitting an extension, so please let me know if I have made mistakes. Thanks for your consideration!

[CLAassistant]

All committers have signed the CLA.

[Tobski]

Couple comments but overall looks good to me - should have some more eyes before accepting though, and ideally an implementation in at last draft form. Thanks for putting this together!

[Tobski]

This example using spirv_string is weird, given that's not introduced here. I suggest picking something else as the example for this spec so it can be a standalone.

[rdb]

You're right, I'll make up some example that works without spirv_string.

[Tobski]

This should be stated somewhere in the actual spec body - I don't see anything banning this. Issues are only for clarifications, but they should be backed up by the spec.

[rdb]

This is the main grammar production added:

spirv_instruction-qualifier function_prototype_with_variadic_tail SEMICOLON

There's no reference to the variadic tail anywhere else, so a variadic tail on user-defined functions is already invalid syntax - should there be explicit prose banning it as well?