racz16 / WebGL-GLSL-Editor

WebGL GLSL shader editor extension for Visual Studio Code.
Other
97 stars 12 forks source link

Language server breaks down on buffer statements #47

Closed Kwonunn closed 1 year ago

Kwonunn commented 1 year ago

I'm using the extension to write GLSL code, and I am using a SSBO. In the .frag file, everything before the buffer declaration works as normal, but everything after the buffer declaration completely falls apart. The formatter breaks, the outline doesn't show any symbols after the buffer and intellisense doesn't know about anything after the buffer.

I'm pretty sure I'm not breaking any syntax by having this buffer here, and even if I was it'd be nice if the extension just ignored this part and didn't completely break for the rest of the file.

The buffer declaration: image The code after the buffer declaration: image The outliner before and after: image

racz16 commented 1 year ago

The SSBO and the buffer qualifier you try to use are only available from GLSL version 430 and 310 es, while my extension only supports version 100 and 300 es. So while your syntax is valid in certain GLSL versions, my extension doesn't support those versions (the extension's name is WebGL GLSL Editor, because it only supports GLSL versions available in WebGL).

Unfortunately, making the extension work even with invalid syntax is not always easy. If you change the version declaration to #version 300 es, you'll see that not only the buffer qualifier is not available, but also an array declaration without a size, std430 and binding are not valid. However, if you change buffer to uniform, the extension will be able to work somewhat properly and handle the whole file. So there is a bit of flexibility, it could handle 3 out of 4 syntax errors, but unfortunately not buffer.

I don't think I can just skip the invalid parts of the code and handle the parts after it. I can see that after your SSBO there are 2 comments and then a variable declaration. However, ANTLR, which does the parsing doesn't know what an SSBO is and therefore it can't determine where it ends. So from the layout qualifier to the end of the file, it can only see an invalid list of tokens.

I have workarounds, but they're pretty ugly.

#define uniform buffer
layout(std430, binding = 3) uniform some_data {
    Tri data_SSBO[];
};
#undef uniform

My extension doesn't expand macros, so now it sees it as a uniform buffer, but in reality, after the macro expansion, it'll be an SSBO. Yeah, so it's ugly, but somewhat working. Another workaround is to put the whole SSBO into a macro like this:

#define SSBO layout(std430, binding = 3) buffer some_data { Tri data_SSBO[]; }
SSBO;

At the weekend I'll take a deeper look into the code, maybe I can find a reasonable solution to better handle invalid syntax, but I'm not sure it is possible, so don't have high hopes.

The last thing I'd like to mention is that I started to work on a GLSL language server, which will solve the problem. It'll support all 17 GLSL versions, it'll support preprocessor directives, it'll be also available in Visual Studio, and much more. You can find the source code here. In recent times I'm pretty busy with other projects, so I couldn't work on it, but I hope I can continue the development soon. So eventually it'll solve the problem and this extension will be deprecated in favor of the new one, but it'll take time because for example, I'll have to write my own GLSL preprocessor, which is not a trivial task.

Kwonunn commented 1 year ago

Ah, I didn't know this was a 430 feature. Thank you for the comprehensive and quick response! I'll probably be able to work with one of the workarounds.

Good luck with the GLSL extension!