Detect and warn about uninitialized `i` index/counter variables in `for` loops

[Swyter]

So this is related to this Mesa bug: https://bugs.freedesktop.org/show_bug.cgi?id=105755

Turns out that the Mesa compiler detects and throws warnings when variables are potentially uninitialized while the reference compiler does not. This is specially important to avoid undefined behavior and infinite loops that may completely lockup the system, specially because glslangValidator is used as the de facto linter for GLSL.

$ bin/glslparsertest foo.frag pass 1.30
Successfully compiled fragment shader foo.frag: 0:54(14): warning: `i' used uninitialized
0:58(39): warning: `i' used uninitialized
0:59(53): warning: `i' used uninitialized
0:61(30): warning: `i' used uninitialized
0:62(33): warning: `i' used uninitialized
0:54(30): warning: `i' used uninitialized

PIGLIT: {"result": "pass" }

[swyter@osgiliath lnxbuildtest]$ glslangValidator -v foo.frag
Glslang Version: Overload400-PrecQual.2000 12-Apr-2017
ESSL Version: OpenGL ES GLSL 3.20 glslang Khronos.Overload400-PrecQual.2000 12-Apr-2017
GLSL Version: 4.60 glslang Khronos.Overload400-PrecQual.2000 12-Apr-2017
SPIR-V Version 0x00010000, Revision 12
GLSL.std.450 Version 100, Revision 1
Khronos Tool ID 8
SPIR-V Generator Version 3
GL_KHR_vulkan_glsl version 100
ARB_GL_gl_spirv version 100
[swyter@osgiliath lnxbuildtest]$ 

Maybe this case should be handled better.

PS: Here is the test-case: uninitialized-for-loop-counter-variable-glsl-example.zip

[MarkY-LunarG]

I have seen the same issue in my own personal shader. In my case, though, the value was a uint not used by a loop but that was only used with increment:

  uint j;
  for (uint i = 0; i < 300; i++) {
     if (some_condiition_met) {
        j++;
     }
  }
 uvec3 color = uvec3(j / 300);

This was for a Julia-set shader I was working on: my_bad_julia_shader.txt.

It took me 2 or 3 days to diagnose the issue as an uninitialized variable compiling with only glslangValidator.