[Feature Request] Allow specifying semantics to glslangValidator

[bwpge]

Just stumbled across this extension and I just wanted to say this is fantastic work. Thank you for this!

My current use case is a desktop application for Vulkan, and I'd like to specify to the compiler I'm using it (e.g., push_constant causes an error which is obviously by design for this extension). The other diagnostics are quite useful, so I'd prefer to not turn them off entirely.

It could even just be a setting allowing the user to specify Vulkan validation with the understanding this is not "core" functionality of the extension -- something like:

{
    "webgl-glsl-editor.validateVulkanExperimental": true  // default: false
}

I realize this has some complications, as -V and -G produce output files, so it might have to use a hacky workaround like -V -o '' and ignore the "failed to open file" error.

I also understand this is a WebGL extension so it's not really the goal to be a "Vulkan" extension. But this option would make the extension quite awesome for users outside of WebGL.

[Rácz Zalán]

Thanks, I'm glad you like it. It seems that a lot of people use my extension with desktop GLSL versions and that's why I started to create a new extension. It'll support all GLSL versions and Vulkan, it'll have full preprocessor support, better embedded language support, it'll be available in Visual Studio, and a lot of other stuff. You can find the language server here: https://github.com/racz16/GLSL-Language-Server. I'm a bit busy, so the progress is pretty slow, but the diagnostic part is more or less working and currently, I'm working on the syntax highlight. I'm still not sure how to support Vulkan: with an option in the preferences, with a special comment in the source code, or some other way. When I finish diagnostics and syntax highlight I plan to release the initial version. In the meantime, you have a few (but not very good workarounds). You can disable diagnostics, you can ignore Vulkan-related errors or you can use macros. For example, you can write something like this:

#ifdef VULKAN
  #define PUSH_CONSTANT push_constant
#else
  #define PUSH_CONSTANT 
#endif

and use it where you'd use push_constant. Since my extension doesn't support Vulkan, it'll expand PUSH_CONSTANT to an empty string, so my extension's compiler won't complain that it doesn't know it. However, your compiler will generate a macro named VULKAN, so you'll get the correct SPIR-V binary. This is not the nicest solution and it can become a bit complicated over time and of course, adds a lot of noise, but at least it's somewhat working. But later you'll be able to switch to the other extension, where it'll just work. I hope it helped.

[bwpge]

Thank you for the detailed feedback! Totally makes sense, and appreciate the workaround info.

I'm super busy this week but when I get some time I'll take a look at your language server extension and see if I can contribute any help. Appreciate you taking on so much burden for the betterment of the community :)