glsl: fail when a shader's input var has not an equivalent out var in previous

GLSL ES 3.00 spec, 4.3.10 (Linking of Vertex Outputs and Fragment Inputs),
page 45 says the following:

"The type of vertex outputs and fragment input with the same name must match,
otherwise the link command will fail. The precision does not need to match.
Only those fragment inputs statically used (i.e. read) in the fragment shader
must be declared as outputs in the vertex shader; declaring superfluous vertex
shader outputs is permissible."
[...]
"The term static use means that after preprocessing the shader includes at
least one statement that accesses the input or output, even if that statement
is never actually executed."

And it includes a table with all the possibilities.

Similar table or content is present in other GLSL specs: GLSL 4.40, GLSL 1.50,
etc but for more stages (vertex and geometry shaders, etc).

This patch detects that case and returns a link error. It fixes the following
dEQP test:

  dEQP-GLES3.functional.shaders.linkage.varying.rules.illegal_usage_1

However, it adds a new regression in piglit because the test hasn't a
vertex shader and it checks the link status.

bin/glslparsertest \
tests/spec/glsl-1.50/compiler/gs-also-uses-smooth-flat-noperspective.geom pass \
1.50 --check-link

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
glsl: invariant qualifier is not valid for shader inputs in GLSL ES 3.00

GLSL ES 3.00 spec, chapter 4.6.1 "The Invariant Qualifier",

    Only variables output from a shader can be candidates for invariance. This
    includes user-defined output variables and the built-in output variables.
    As only outputs can be declared as invariant, an invariant output from one
    shader stage will still match an input of a subsequent stage without the
    input being declared as invariant.

This patch fixes the following dEQP tests:

dEQP-GLES3.functional.shaders.qualification_order.variables.valid.invariant_interp_storage_precision
dEQP-GLES3.functional.shaders.qualification_order.variables.valid.invariant_interp_storage
dEQP-GLES3.functional.shaders.qualification_order.variables.valid.invariant_storage_precision
dEQP-GLES3.functional.shaders.qualification_order.variables.valid.invariant_storage
dEQP-GLES3.functional.shaders.qualification_order.variables.invalid.invariant_interp_storage_precision_invariant_input
dEQP-GLES3.functional.shaders.qualification_order.variables.invalid.invariant_interp_storage_invariant_input
dEQP-GLES3.functional.shaders.qualification_order.variables.invalid.invariant_storage_precision_invariant_input
dEQP-GLES3.functional.shaders.qualification_order.variables.invalid.invariant_storage_invariant_input

No piglit regressions observed.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
glsl: don't allow invariant qualifiers for interface blocks in GLSL ES

From GLSL ES 3.0, chapter 4.3.7 "Interface Blocks", page 38:

"GLSL ES 3.0 does not support interface blocks for shader inputs or outputs."

and from GLSL ES 3.0, chapter 4.6.1 "The invariant qualifier", page 52.

"Only variables output from a shader can be candidates for invariance. This
includes user-defined output variables and the built-in output variables. As
only outputs can be declared as invariant, an invariant output from one shader
stage will still match an input of a subsequent stage without the input being
declared as invariant."

From GLSL ES 1.0, chapter 4.6.1 "The invariant qualifier", page 37.

"Only the following variables may be declared as invariant:
* Built-in special variables output from the vertex shader
* Varying variables output from the vertex shader
* Built-in special variables input to the fragment shader
* Varying variables input to the fragment shader
* Built-in special variables output from the fragment shader."

This patch fixes the following dEQP tests:

dEQP-GLES3.functional.shaders.declarations.invalid_declarations.invariant_uniform_block_2_vertex
dEQP-GLES3.functional.shaders.declarations.invalid_declarations.invariant_uniform_block_2_fragment

No piglit regressions.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
glsl: A shader cannot redefine or overload built-in functions in GLSL ES 3.00

Create a new search function to look for matching built-in functions by name
and use it for built-in function redefinition or overload in GLSL ES 3.00.

GLSL ES 3.0 spec, chapter 6.1 "Function Definitions", page 71

"A shader cannot redefine or overload built-in functions."

In case of GLSL ES 1.0 spec, chapter 6.1 "Function Definitions", page 54

"Function names can be overloaded. This allows the same function name to be
used for multiple functions, as long as the argument list types differ. If
functions’ names and argument types match, then their return type and
parameter qualifiers must also match. Function signature matching is based on
parameter type only, no qualifiers are used. Overloading is used heavily in the
built-in functions. When overloaded functions (or indeed any functions) are
resolved, an exact match for the function's signature is sought. This includes
exact match of array size as well. No promotion or demotion of the return type
or input argument types is done. All expected combination of inputs and
outputs must be defined as separate functions."

So this check is specific to GLSL ES 3.00.

This patch fixes the following dEQP tests:

dEQP-GLES3.functional.shaders.functions.invalid.overload_builtin_function_vertex
dEQP-GLES3.functional.shaders.functions.invalid.overload_builtin_function_fragment
dEQP-GLES3.functional.shaders.functions.invalid.redefine_builtin_function_vertex
dEQP-GLES3.functional.shaders.functions.invalid.redefine_builtin_function_fragment

No piglit regressions.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
main/glsles: return two minor digits for SHADING_LANGUAGE_VERSION

For OpenGL ES 3.0 spec, the minor number for SHADING_LANGUAGE_VERSION is always
two digits, matching the OpenGL ES Shading Language Specification release
number. For example, this query might return the string "3.00".

This test fixes the following dEQP test:

   dEQP-GLES3.functional.state_query.string.shading_language_version

No piglit regression observed.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>