search

KhronosGroup / glslang

Khronos-reference front end for GLSL/ESSL, partial front end for HLSL, and a SPIR-V generator.
Other
2.9k stars 816 forks source link

[glslangValidator] Column of error report always zero #3238

Open FrostKiwi opened 1 year ago

FrostKiwi commented 1 year ago

Installed the MSYS2 package mingw-w64-x86_64-glslang in the MinGW64 environment to allow VSCode to lint Shaders via https://github.com/hsimpson/vscode-glsllint

I created GLSL errors and ran glslangValidator project.vert project.frag in the Mingw64 environment of MSYS2. It outputs the column of an error as always zero. See screenshot of the Windows Terminal at the very bottom.

Sample output ```console $ glslangValidator project.vert project.frag project.vert ERROR: 0:4: '' : syntax error, unexpected IDENTIFIER, expecting LEFT_BRACE or COMMA or SEMICOLON ERROR: 1 compilation errors. No code generated. project.frag ERROR: 0:10: 'normze' : no matching overloaded function found ERROR: 0:10: '=' : cannot convert from ' const float' to ' temp highp 3-component vector of float' ERROR: 0:10: '' : compilation terminated ERROR: 3 compilation errors. No code generated. ```
glslangValidator --version ``` Glslang Version: 11:12.1.0 ESSL Version: OpenGL ES GLSL 3.20 glslang Khronos. 12.1.0 GLSL Version: 4.60 glslang Khronos. 12.1.0 SPIR-V Version 0x00010600, Revision 1 GLSL.std.450 Version 100, Revision 1 Khronos Tool ID 8 SPIR-V Generator Version 11 GL_KHR_vulkan_glsl version 100 ARB_GL_gl_spirv version 100 ```

This results in the linter always displaying error squiggles at the first token of the line, which is visually unpleasing and an extra workflow step of mouse-overing that squiggles to understand what's actually going on. image image

arcady-lunarg commented 1 year ago

This is unfortunately a longstanding issue with the parser in glslang. By the time some errors are generated, some of the column information has already been lost. This is definitely a bug that we need to fix though.

antaalt commented 1 month ago

I was interested by this issue, after looking a bit into this, it seems the zero is not the column but the TSourceLoc::string integer that is printed, which I don't really get what use it is for... The column is simply not printed at all even though it looks valid in the code. It could be fixed easily by adding it to the log, but it will break the log format on which some external application might be relying to parse the errors (such as vscode-glsllint), so that might be a breaking change...