<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Wrong shader compilation error message" href="https://bugs.freedesktop.org/show_bug.cgi?id=96729#c1">Comment # 1</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Wrong shader compilation error message" href="https://bugs.freedesktop.org/show_bug.cgi?id=96729">bug 96729</a> from <a class="email" href="mailto:imirkin@alum.mit.edu" title="Ilia Mirkin <imirkin@alum.mit.edu>"> Ilia Mirkin</a> <pre>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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>