> 14/23 glsl: Add an internal-error catch-all rule > In your updated commit message (on git branch), you mention that > this fixes two Khronos negative tests. But, it looks like we will > now print an "Internal compiler error" error message. So, we'll fail > to compile the negative tests, yet report that we have a compiler > error? > > Does the 15 patch fix the error reported? If so, then maybe you can > update the commit messages of the two patches? Also, if patch 15 > fixes the error message, then add my Reviewed-by for this patch.
Thanks again for the careful eye. You are correct that patch 15 fixes these tests for real. But it was at patch 14 that the tests changed from "Fail" to "Pass", (but for the wrong reason). I've updated both commit messages to make things more clear. > Do we have a make check test for the errors that this fixes? Good question. The test here is an extension name being passed to #extension with a non-ASCII character in it. This non-ASCII character is explicitly illegal according to the GLSL specification, (where non-ASCII characters are allowed only in comments). But with our current code, glcpp doesn't enforce this ASCII-only requirement, while the subsequent glsl compiler does. So we would need to write some additional code for glcpp (without any real benefit) before we could use glcpp's "make check" rigging to test this. > 23/23 glsl/glcpp: Treat carriage return as equivalent to line feed. > Should we add this before the patch that will cause the error to be > generated? Yes. That is more in line with the mesa approach to code history for bug fixes. I've re-ordered these and updated the commit messages as necessary. -Carl -- carl.d.wo...@intel.com
pgpJYBRGjrXGu.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
