GLSLang should throw an error when a shader input or output variable does not have a location

[gfxstrand]

From the Vulkan 1.0.43 spec:

The remaining variables listed by OpEntryPoint with the Input or Output storage class form the user-defined variable interface. By default such variables have a type with a width of 32 or 64. If an implementation supports storageInputOutput16KHX, user-defined variables in the Input and Output storage classes can also have types with a width of 16. These variables must be identified with a Location decoration and can also be identified with a Component decoration.

So it's invalid to have a user-defined interface variable that does not have a location specifier. When building shaders for Vulkan, GLSLang should throw an error whenever a location specifier isn't provided. Perhaps we also need something added to the vulkan GLSL extension spec?

[johnkslang]

A front-end could auto-assign locations, either based on order, or on having multiple stages present at the same time, so maybe there should not be a GLSL specification change.

Khronos has requested that glslang give an error on GLSL shaders missing location information, so will do that.

[warp-10]

Related: #918, which requests an option for the exact opposite behavior.

I've encountered two "modes" of using GLSL: Letting shaders control resource mappings, and binding by name, ignoring layout specifiers.

Maybe an extension enabled at the shader level would make this distinction clear to anything parsing the resulting SPIR-V?

Code with the extension enabled would not require layout specifiers (preferably report errors where they appear), and the resulting bytecode would have OpDecorate location/set/bindng with some reserved constant to indicate "undefined", where the renderer could then fill in the details before passing it to the driver.

The driver, encountering any unprocessed code generated with that extension, could unambiguously reject it.

[johnkslang]

I need to close this issue, as it has been fixed a couple weeks ago. Let's continue the discussion about relaxing things in #918.

Note also, I included a --auto-map-locations option that can be fleshed out in the io-mapper for this specific case.