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

[Timothy Arceri]

On 17/9/18 7:56 pm, Danylo Piliaiev wrote:
> On 9/17/18 12:28 PM, Timothy Arceri wrote:
>> On 16/8/18 12:23 am, Danylo Piliaiev wrote:
>>> 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;
>>
>> This looks like it should be split into two different tests. Is there 
>> any reason you included both tests together?
> The reason was is that the only thing that is tested here is that Mesa 
> doesn't crash when compiling the shader.
> Testing whether the assignment of an incompatible type produces an error 
> is on the other tests.
> I'm not sure at this moment if that was a good reason. I can split it 
> into two tests if you find it necessary.

Regardless of what you are testing you still have two tests here. If 
they can both trigger a segfault in different paths they should be spilt 
in two. If they both test the a segfault in the same place then we 
should probably simplify the test.

>>
>>> +}
>>>
>