Consider the following vertex shader: #version 120 vec4 toColor(float x) { ivec4 v=ivec4(0,0,0,0); v.y+=128*x; return v*1.; } void main() { gl_Position=gl_ModelViewProjectionMatrix*gl_Vertex; vec4 c=toColor(0.); gl_FrontColor=vec4(c.rgb,1); } 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[0]'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. https://patchwork.freedesktop.org/patch/97904/
Fix pushed: commit a32c87f74be1beed546d6d8853933d1b48f42f18 Author: Ilia Mirkin <imirkin@alum.mit.edu> 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. How we collect and use information is described in our Privacy Policy.