error in combination with preprocessor directives can obfuscate error location. about glslang HOT 4 OPEN

Yeah, I think ultimately the way to deal with this is to keep track of the start of the unterminated statement. Part of the issue is that #include processing happens in the tokenizer, at a level below that of the glslang.y bison parser. Error reporting is definitely an area where glslang could use considerable improvement, patches are definitely welcome.

from glslang.

@arcady-lunarg good to hear you concur with my line of thought. Do you have any highlevel pointers in terms of 'glslang.y', it's hard to understand thirdparty code at face value, so I'm wondering what generally would work best.

What I had in mind:

• I assume that you that this error statements in particulair are auto generated, so I'd have to patch up the catch all error handler.
• I assume that some kind of global context is available from bison, that is also available during the error handler(s)
• I'm thinking some kind of inline code to identify when statements are opened and terminated (state-machine)
• The part where the auto generated errors are handled then simply use the additional (context-)information to report altered locations.

Would this be a solid approach, keeping in mind, I'd like to refrain from seriously affecting other errors. Do you have an alternative/better suggestion?

from glslang.

I recommend reading up on how bison generated grammars work, but the key glslang-specific pieces you want to look at here is the TParseContext class, and the interm struct in glslang.y, and in particular its loc member of type TSourceLoc.

from glslang.

@arcady-lunarg I have prepared a pull request of the initial changes I drafted, it'd be great if you could have a look to see if you had any comments on it: #3559

from glslang.