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

[Danylo Piliaiev]

On 9/17/18 1:01 PM, Timothy Arceri wrote:
> 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.
>
Understood, I'll split it in to two tests. Only one case is causing 
segfault, other one just has a potential.
>>>
>>>> +}
>>>>
>>