Consider the following vertex shader:
vec4 toColor(float x)
It contains an error of implicit conversion of float to integer. But what I get in Mesa's info log instead is:
0:6(2): error: non-lvalue in assignment
And this is despite v.y is an lvalue.
This is happening because there's a ast_add_assign node, which first figures out the compatible type based on the add operation, and implicitly converts the "other" side. So we end up with
(i2f v.y) += (128 * x)
And of course the i2f isn't an lvalue, hence the error. The issue is that ast_to_hir.cpp::arithmetic_result_type has no concept that an assignment is taking place, and happily applies the conversion. My initial thought was that we should pass the fact that it's an assignment through, but that gets a little nasty.
My second thought is that in an assign situation, the arithmetic_result_type has to return the (original) op's type. If not, then we should throw an error. And this applies to all the other instances of this.
This patch changes the error on the supplied shader.
Author: Ilia Mirkin <firstname.lastname@example.org>
Date: Fri Jul 8 23:28:22 2016 -0400
glsl: emit a specific error when ast_*_assign changes type
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.