Cleaning the implementation of GL_EXT_texture_shadow_lod. Moving the

[pmistryNV]

parameter verification to a centralized place where all other built-ins are verified for correctness.

[pmistryNV]

@alelenv please take a look

[ncesario-lunarg]

LGTM pending CI.

[pmistryNV]

I need to clean it up a bit more. Kindly hold on the merge for a day.

[alelenv]

@ncesario-lunarg or @arcady-lunarg : Can you clarify why was TempParser added in first place?
It seems pretty inelegant way to do it compared to pmistryNV's current change
Are we missing some edge case?

[ncesario-lunarg]

@alelenv The "TempParser" was added as a workaround for getting the mangled name of a function, as currently the only way to get the mangled name of a function name is by running the full parser. The end goal was to associate only specific overloads of a function with a given extension (GL_EXT_texture_shadow_lod in this case). At the time I made the change it seemed like a more "direct" route than adding some manual type checking later, but I'm in favor of getting rid of the temp parser as it was always a hack.

[pmistryNV]

General feedback since glslang is the reference compiler for GLSL, it's paramount that any extension implemented should have extensive coverage:

1. Appropriate version control check for ES and GL version.
2. If certain arguments or signatures are not suppose to compile with certain version or with certain set of extension then that should be covered. For example for this extension there is a dependency on OES_texture_cube_map_array, EXT_texture_cube_map_array in GLES. However dependency on ARB_texture_cube_map_array is not necesary to capture because token "samplerCubeArrayShadow" is turned on by default. For any builtins TParseContext::builtInOpCheck is the appropriate place to check for any dependencies that the grammar file cannot capture.
3. Extensive set of test cases should be added for passing and failing cases for both ES and GL.

This helps anyone using the compiler to cross validate the correctness of the spec. Having a buggy implementation makes the user confused and causes the spec to be not implemented correctly in shaders.

[pmistryNV]

@ncesario-lunarg @arcady-lunarg kindly review and merge this change.

[arcady-lunarg]

Given that this is not an "error" test, is it supposed to be producing errors here?

[pmistryNV]

This covers both errors and non errors. This is in line with other glsl shaders. Where both good and bad cases are kept in the same shader file.

[pmistryNV]

feel free to add more test case as a follow up change. I just wanted to clean it up. Validation is now correct. We can add more test cases for ES.

[arcady-lunarg]

I corrected the grammar on the commit message a bit, in general we prefer that those are written in the simple present. Thanks for the cleanup and the good commit message.