[Piglit] [PATCH] glsl-1.10: add a 'initialization-incompatible-type-propagation' test

[Danylo Piliaiev]

This tests the case when initialising with incompatible type
changed a type of the variable being initialized.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107547

Signed-off-by: Danylo Piliaiev <danylo.piliaiev at globallogic.com>
---
I'm not sure if it's a proper way to test this. The compilation is intended to
fail but the difference is in the error messages. The correct message is an 
error in initialization line and no errors in accessing to the variables, 
incorrect - additional errors where variables are accessed.
At the moment it tests only that compiler wouldn't crash which happened
in the mentioned bug and fix proposed in
https://patchwork.freedesktop.org/series/48256/

 ...ization-incompatible-type-propagation.frag | 27 +++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag

diff --git a/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag b/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag
new file mode 100644
index 000000000..0a1873489
--- /dev/null
+++ b/tests/spec/glsl-1.10/compiler/initialization-incompatible-type-propagation.frag
@@ -0,0 +1,27 @@
+// [config]
+// expect_result: fail
+// glsl_version: 1.10
+// [end config]
+//
+// Initializing a variable using the variable with a wrong type
+// should not affect the type of the variable being initialized.
+// At least it should not crash, see bug:
+// https://bugs.freedesktop.org/show_bug.cgi?id=107547
+//
+// From section 5.8 of the GLSL 1.10 spec:
+//     The assignment operator stores the value of expression into lvalue.
+//     It will compile only if expression and lvalue have the same type.
+
+#version 110
+
+uniform struct {
+        float field;
+} data;
+
+int f() {
+    vec4 a = vec2(0.0);
+    a.w -= 1.0;
+
+    vec2 b = data;
+    b.x -= 1.0;
+}
-- 
2.18.0