glsl-language-server icon indicating copy to clipboard operation
glsl-language-server copied to clipboard

Published 20 hours ago • verified publisher icon svenstaro

crash when failing to discover language by extension

Open chergert opened this issue 2 years ago • 5 comments

Currently glslls just crashes if it can't discover the extension, which can create a lot of core dumps over time. Might be nice to just send an error back to the client.

chergert avatar Oct 06 '22 00:10 chergert

@nolanderc wanna take a stab at this?

svenstaro avatar Apr 30 '23 22:04 svenstaro

I have been running into this myself after I added support for #include: I have split some common functionality into separate files, but seeing as they can be used in both compute, vertex and fragment shaders, I decided to give them the extension .glsl. However, as this is not a recognized extension, the language server crashes. As I see it, we have two options:

  1. Provide an error message, as suggested by @chergert, to stop the server from crashing (might be nice to have in some other situations as well).
  2. Assume any unrecognized extension is a generic GLSL file, and fall back to some default behaviour. This could allow the server to provide some basic support such as code completion, but may reduce the accuracy of diagnostics.

Unfortunately, it does not seem as if glslang provides an enum variant for such a "generic" shader language. Maybe we could just assume a compute shader, or similar, as they should be closest to a superset of all others?

nolanderc avatar May 01 '23 09:05 nolanderc

How about a warning + sane default as you suggested?

svenstaro avatar May 01 '23 11:05 svenstaro

I'm also interested in this. Recently I started going over some playlists at https://www.youtube.com/@TheCherno. He has stuff on OpenGL, Game Engines, C++ in general etc.

I think it was in one of his videos from the OpenGL playlist (possibly this one: https://youtu.be/2pv0Fbo-7ms but I'm not sure) where he explains that one of the systems he wants to build is to have one file for multiple shader types. We can probably take a look at how they handle code recognition in that project through some file splitting method. I assume something like this can be done for an LSP as well, but I'm not even an amateur with LSPs so I can't say more.

razcore-rad avatar May 27 '23 10:05 razcore-rad

If there is interest in automatically handling concatenated files, that would certainly be nice. GTK does this, which is what I would want to use this for when working on GTK's GL renderer.

$ cat blend.glsl
// VERTEX_SHADER:
// blend.glsl
...
// FRAGMENT_SHADER:
// blend.glsl
...

chergert avatar May 30 '23 20:05 chergert