nolanderc/glsl_analyzer

Language server for GLSL (autocomplete, goto-definition, formatter, and more)

glsl_analyzer's Issues

Implement goto-definition for fields

struct Foo {
    int abc;
} foo;

void main() {
    foo.abc;
}

With the cursor on abc in main, we should get hover info and goto-definition should move into the struct.

Windows/Neovim Segmentation Fault

The language server didn't seem to work inside my neovim, so I tried to test the binary directly by providing a file with the --parse-file option and it caused segmentation fault. Both the binary provided here and that built from source (with Zig 0.12) have the same problem. This looks like an issue with Zig, but I'm not sure.

Segmentation fault at address 0x16424d3008d
/opt/hostedtoolcache/zig/0.12.0/x64/lib/std/fs/Dir.zig:800:56: 0x6c1f6a in openFile (glsl_analyzer.exe.obj)      
/opt/hostedtoolcache/zig/0.12.0/x64/lib/std/fs/Dir.zig:1873:37: 0x6c219b in readFileAlloc (glsl_analyzer.exe.obj)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/main.zig:55:50: 0x6e79e7 in main (glsl_analyzer.exe.obj)       
/opt/hostedtoolcache/zig/0.12.0/x64/lib/std/start.zig:484:75: 0x6eee66 in main (glsl_analyzer.exe.obj)
/opt/hostedtoolcache/zig/0.12.0/x64/lib/libc/mingw/crt/crtexe.c:267:0: 0x74e515 in __tmainCRTStartup (crt2.obj)  
/opt/hostedtoolcache/zig/0.12.0/x64/lib/libc/mingw/crt/crtexe.c:188:0: 0x74e565 in mainCRTStartup (crt2.obj)     
???:?:?: 0x7ff8e5907343 in ??? (KERNEL32.DLL)
???:?:?: 0x7ff8e78fcc90 in ??? (ntdll.dll)

OS info:

Edition: Windows 10 Home
Version: 22H2
OS build: 19045.4529

cant work in neovim

I'm using a setup similar to lazyvim with nvimdots on Windows 11. Following issue #51, I've installed and set up vim-glsl, and file types are successfully recognized as glsl. However, it seems that only vim-glsl is working properly, and the features related to glsl-analyzer (like go to definition, formatting, etc.) are not functioning.
My configuration is as follows.

this does not print "attached" when i open an .vert or .frag file.
When I use 'go to definition,' the following error occurs.

:LspInfo

Weird closing bracket formatting on array literals

struct HeightData {
    float offset;
    float scale;
    float impact;
};

const HeightData height_data[] = {
    HeightData(0.0, 0.0, 0.0),
    HeightData(0.2, 2.0, 0.35),
    HeightData(0.0, 0.0, 0.0),
    HeightData(0.4, 7.0, 0.2),
    HeightData(0.6, 20.0, 0.5),
    HeightData(0.0, 0.0, 0.0),
    HeightData(0.8, 2.0, 0.35),
    HeightData(0.1, 1.0, 0.35),
    HeightData(0.0, 0.0, 0.0),
    HeightData(0.0, 0.0, 0.0),
};

Formats to

struct HeightData {
    float offset;
    float scale;
    float impact;
};

const HeightData height_data[] = {
    HeightData(0.0, 0.0, 0.0),
    HeightData(0.2, 2.0, 0.35),
    HeightData(0.0, 0.0, 0.0),
    HeightData(0.4, 7.0, 0.2),
    HeightData(0.6, 20.0, 0.5),
    HeightData(0.0, 0.0, 0.0),
    HeightData(0.8, 2.0, 0.35),
    HeightData(0.1, 1.0, 0.35),
    HeightData(0.0, 0.0, 0.0),
    HeightData(0.0, 0.0, 0.0),
    };

This looks wrong to me.

#include not working in vscode on windows

When using vscode on windows, using #include results in BadPathName errors in the log. However, when I ctrl-click on one of the paths printed in the errors, vscode succesfully opens the file, so the paths seem to be valid.
Interestingly, the susccessfully opened paths in the log all seem to use / as the separator, and the errored paths have \\ in them.

False error 'missing semicolon' with macros

I'm getting false errors claiming a missing semicolon, specifically for the below case of macro replacements of a for loop, which could suggest the syntax is not defined entirely correctly, or just be a symptom of macros not being preprocessed.

#version 450

#define FOREACH(x) for (x = 0; x < 42; x++)

void main() {
    uint x, y;
    FOREACH(x) {
        y += x;
    }
}

Produces this tree and error messages:

glsl_analyzer --parse-file shaders/src/bug.comp --print-ast
file
  function_declaration
    identifier 'void'
    identifier 'main'
    parameter_list
      (
      )
    block
      {
      declaration
        identifier 'uint'
        variable_declaration_list
          variable_declaration
            identifier 'x'
            ,
          variable_declaration
            identifier 'y'
        ;
      statement
        call
          identifier 'FOREACH'
          (
          argument
            identifier 'x'
          )
        invalid
      block
        {
        statement
          assignment
            identifier 'y'
            +=
            identifier 'x'
          ;
        }
      }
shaders/src/bug.comp:7:15: expected ;

glsl_analyzer version: 1.4.5

Parser crash in the binary expression with the `&&` operator

glsl_analyzer v1.0.8
glsl_analyzer-vscode v1.2.2

Hi, parser seems to crash in this small snippet:

#version 430 core

void main() {
    true && true;
}

Seems to happen around && independent of the operand expression type.
|| is fine, but maybe other operators are affected too.

Here's the output log:

[Error - 5:00:39 PM] Server process exited with signal SIGABRT.
[Info  - 5:00:39 PM] Connection to server got closed. Server will restart.
true
debug: method: 'initialize'
debug: method: 'initialized'
debug: method: 'textDocument/didOpen'
debug: opened: file:///home/automatic/projects/josh3d/src/shaders/test2.glsl : glsl : 141 : 53
debug: method: 'textDocument/hover'
debug: hover: 3:4 file:///home/automatic/projects/josh3d/src/shaders/test2.glsl
debug: hover word: 'true'
thread 1755343 panic: reached unreachable code
/home/runner/work/glsl_analyzer/glsl_analyzer/src/parse.zig:0:0: 0x23604b in advance (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/parse.zig:1089:22: 0x2a8743 in postfixExpressionOpt (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/parse.zig:1019:48: 0x2a2b92 in infixExpressionOptImpl (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/parse.zig:978:34: 0x28fb64 in constantExpressionOpt (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/parse.zig:914:31: 0x2a08fd in assignmentExpressionOpt (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/parse.zig:886:33: 0x28fec2 in expressionOpt (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/parse.zig:836:35: 0x282b02 in statement (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/parse.zig:707:22: 0x27b078 in block (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/parse.zig:652:26: 0x236c99 in parseTree (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/Document.zig:133:38: 0x23bcdc in completionsAtPosition (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/main.zig:602:34: 0x23ee25 in textDocument/hover (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/main.zig:273:45: 0x24b62a in dispatchRequest (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/main.zig:247:59: 0x251958 in main (glsl_analyzer)
/opt/hostedtoolcache/zig/0.12.0-dev.790/x64/lib/std/start.zig:486:37: 0x253eba in main (glsl_analyzer)
/opt/hostedtoolcache/zig/0.12.0-dev.790/x64/lib/libc/musl/src/env/__libc_start_main.c:95:7: 0x2b0ae2 in libc_start_main_stage2 (/opt/hostedtoolcache/zig/0.12.0-dev.790/x64/lib/libc/musl/src/env/__libc_start_main.c)
Unwind error at address `exe:0x2b0ae2` (error.AddressOutOfRange), trace may be incomplete

[Error - 5:00:40 PM] Server process exited with signal SIGABRT.
[Error - 5:00:40 PM] The glsl_analyzer server crashed 5 times in the last 3 minutes. The server will not be restarted. See the output for more information.

Formatting duplicates comments

When formatting with glsl_analyzer, multiline block comments seem to duplicate.

/** Some 
 * long 
 * multiline comment
 */


/** Remapping from input array to output array.
 * m_primitive_list[primitive_remap_index[i]] = m_primitive_list_in[i] */
layout(binding = 4, std430) buffer primitivesRemapSSBOOut {
	uint primitive_remap_index[];
};

becomes

/** Some
 * long
 * multiline comment
/** Some 
 * long 
 * multiline comment
 */

/** Remapping from input array to output array.
/** Remapping from input array to output array.
 * m_primitive_list[primitive_remap_index[i]] = m_primitive_list_in[i] */
layout(binding = 4, std430) buffer primitivesRemapSSBOOut {
    uint primitive_remap_index[];
};

This is not an issue with multiple lines of C++ style line comments.

Same goes for multiline defines:

#define SNIPPET(x) \
do { \
x ++; \
} while (0)

becomes

#define SNIPPET(x) \
do { \
x ++; \
#define SNIPPET(x) \
do { \
x ++; \
} while (0)

This might be connected to line endings, as these two cases are syntax which ignore line endings.

Package in Fedora

@nolanderc seems interested in having this project packaged in Fedora.
I as a package maintainer can take some steps to do it.
Firstly I need to ask about whether this qualifies as a generic package or whether we need to create guidelines for packaging zig packages.

Missing content in spec.json

Maybe there is some more. Below is just what I found:

All keywords (well, just terminateInvocation from GL_EXT_terminate_invocation afaik) and types from extensions

constants:

• from GL_KHR_memory_scope_semantics

const int gl_ScopeDevice      = 1;
const int gl_ScopeWorkgroup   = 2;
const int gl_ScopeSubgroup    = 3;
const int gl_ScopeInvocation  = 4;
const int gl_ScopeQueueFamily = 5;
const int gl_SemanticsRelaxed         = 0x0;
const int gl_SemanticsAcquire         = 0x2;
const int gl_SemanticsRelease         = 0x4;
const int gl_SemanticsAcquireRelease  = 0x8;
const int gl_SemanticsMakeAvailable   = 0x2000;
const int gl_SemanticsMakeVisible     = 0x4000;
const int gl_SemanticsVolatile        = 0x8000;
const int gl_StorageSemanticsNone     = 0x0;
const int gl_StorageSemanticsBuffer   = 0x40;
const int gl_StorageSemanticsShared   = 0x100;
const int gl_StorageSemanticsImage    = 0x800;
const int gl_StorageSemanticsOutput   = 0x1000;

• from GL_KHR_cooperative_matrix

const int gl_MatrixUseA             = 0;
const int gl_MatrixUseB             = 1;
const int gl_MatrixUseAccumulator   = 2;
const int gl_CooperativeMatrixLayoutRowMajor        = 0;
const int gl_CooperativeMatrixLayoutColumnMajor     = 1;
const int gl_MatrixOperandsSaturatingAccumulation   = 0x10;

functions: (looks like missing functions are always the first function in an extension description file?)

• traceRayEXT() from GL_EXT_ray_tracing
• traceRayMotionNV() from GL_NV_ray_tracing_motion_blur
• hitObjectTraceRayNV() from GL_NV_shader_invocation_reorder

How do we deal with macros?

Macros can appear almost anywhere. For example, in tests/glsl-samples/well-formed/glslang/tokenPaste.vert we have the following line:

float bothpaste(foo, 719);

At first this looks like a function definition, but it is actually macro expansion with:

#define bothpaste(a, b) a##b

The current implementation ignores macro expansion entirely, and just treats it as if it were normal code. This keeps both the tokenizer and parser simple, but has the added benefit of keeping the parse tree a 1:1 correspondence with the source code.

To properly implement macros we would ideally want to include both the pre-expanded tokens, as well as the expanded tokens in the same tree. One possible approach here is to add a special .macro syntax node, which contains the tokens before expansion (used in formatting and hover info, but ignored everywhere else), and then have the expanded tokens in the tree as usual, but with 0-width token spans pointing to the first character of the macro. Spans being 0-width ensures that tokens cannot be hovered, but still have a position for goto-definition.

The parse tree for the above snippet would then look something like the following:

file
  declaration
    identifier "float"@0..5
    macro
      identifier "bothpaste"@6..15
      ( @15..16
      identifier "foo" @16..19
      , @19..20
      number @21..24
      ) @24..25
    identifier "foo123"@6..6
    ; @25..26

Does not compile on Windows with Zig 0.13.0

Problem

Running zig build with version 0.13.0 resulted in the following error:

C:\Users\hyt\workspace\projects\glsl_analyzer\build.zig:78:33: error: no field named 'path' in union 'Build.LazyPath'
        .root_source_file = .{ .path = "src/main.zig" },
                                ^~~~
C:\Users\hyt\scoop\apps\zig\0.13.0\lib\std\Build.zig:2171:22: note: union declared here
pub const LazyPath = union(enum) {
                     ^~~~~
referenced by:
    build: C:\Users\hyt\workspace\projects\glsl_analyzer\build.zig:9:25
    runBuild__anon_8955: C:\Users\hyt\scoop\apps\zig\0.13.0\lib\std\Build.zig:2117:37
    remaining reference traces hidden; use '-freference-trace' to see all reference traces

Commit hash: 3514b23

glsl_analyzer does not compile with Zig 0.12.0

Zig 0.12.0 was just released, but compiling glsl_analyzer with it causes several errors.

I tried fixing some of them, but I don't really have enough time or experience with Zig to completely fix everything. Here's a diff of what I've done so far if you want to use it as a starting point:

zig_12_compatibility.PATCH

Description of exp() wrongly called it "pow"

Line 7215 in spec/spec.json

    {
      "return_type": "genType",
      "name": "exp",
      "parameters": [
        {
          "type": "genType",
          "name": "x"
        }
      ],
      "description": [
        "`pow` returns the natural exponentiation of _x_. i.e., `e**x`."  // <- Here
      ],
      "versions": [
        110,
        120,
        130,
        140,
        150,
        330,
        400,
        410,
        420,
        430,
        440,
        450
      ]
    },

Linting and GLSLANG integration

Hi y'all! I recently started a similar project because I noticed that GLSL didn't have good language integration into VSCode. Language stuff isn't my forte, so I forked a project to get to where I am at now, which is a very minimally working language server, along side a minimal language server vscode extension which I achieved by paying a friend of mine to develop. But it looks like you guys are much more experienced or at least knowledgeable on this subject so I wanted to see if there's anything I can do to assist in the development of this LSP and extension.

One thing my project has is support for compiling via glslang, making compilation errors show up directly in the editor. I would be willing to looking into integrating such a feature into your project, since yours seems much more featureful. I recently spent some time learning Zig, so that's a nice coincidence 😅. I'd love it if I could have an editor that integrates with my Vulkan abstraction in such a way that the same GLSLANG compile commands that are used for compiling shaders in-engine are also used by the extension to show compilation errors, and so they know include paths and such.

Great work on this extension!!

Resolve parser defects

I'll be dumping snippets that confuse/crash the parser here.

Here's a first couple (v1.1.0):

#version 330 core

out Interface {
    vec4 frag_pos;
} out_block;

void main() {
    out_block.frag_pos = gl_in[0].gl_Position; // <- expected ;
}

#version 330 core
void main() {
    if (true) { discard; } // <- expected }
}

Add comprehensive testing for hover and autocomplete

These features are hard to get right, and we have seen some edge cases pop up over the last week.

As far as I understood, the current way of supplying the hover info by walking the parse-tree up is never going to be perfect, so the tests have to be permissive and be more of a warning of where the current approach is not up to the task. Still, seeing the overall picture should be highly beneficial, and should help both make compromises with the current design, as well as assist in integrating the (foreshadowed) type/semantic analysis.

So yeah we need tests.

Crash on hover

Trying to hover anything will result in crash:

debug: hover word: 'normals_uv'
thread 62471 panic: reached unreachable code
/home/runner/work/glsl_analyzer/glsl_analyzer/src/Document.zig:0:0: 0x237662 in parseTree (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/analysis.zig:298:50: 0x23911e in visibleSymbols (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/main.zig:540:57: 0x23c846 in completionsAtPosition (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/main.zig:605:34: 0x23ee55 in textDocument/hover (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/main.zig:276:45: 0x24b65a in dispatchRequest (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/main.zig:250:59: 0x251b98 in main (glsl_analyzer)
/opt/hostedtoolcache/zig/0.12.0-dev.790/x64/lib/std/start.zig:486:37: 0x25414a in main (glsl_analyzer)
/opt/hostedtoolcache/zig/0.12.0-dev.790/x64/lib/libc/musl/src/env/__libc_start_main.c:95:7: 0x2b0d72 in libc_start_main_stage2 (/opt/hostedtoolcache/zig/0.12.0-dev.790/x64/lib/libc/musl/src/env/__libc_start_main.c)
Unwind error at address `exe:0x2b0d72` (error.AddressOutOfRange), trace may be incomplete

Crash does not happen and hover works fine if there are no #include directives in file.
Using latest release x86_64-linux-musl on Ubuntu 20.04.
Please let me know if you need more info.

Resolve parser defects 2: tests from glslang

Ran v1.1.2 through a handpicked subset of tests for glslang. Picked out the files that are:

• GLSL (mostly OpenGL, has some minimal Vulkan dialect, but skipped spv.* files for now);
• not ES (removed es keywords in some files that are otherwise valid core);
• do not test for failure or errors, but are expected to compile (commented out some expected-to-fail lines as well). Was only looking for cases where the code is well-formed, but the parser erroneously disagrees.

Don't have time right now to condense to snippets and minimal repros, but I have this output that points to the problematic files:

FAILED(001): comment.frag:11:7: expected ;
FAILED(002): constantUnaryConversion.comp:26:5: expected ,
FAILED(003): constFoldIntMin.frag:6:23: expected ,
FAILED(004): decls.frag:41:17: expected )
FAILED(005): numeral.frag:78:20: expected ,
FAILED(006): preprocessor.edge_cases.vert:3:17: expected a declaration
FAILED(007): preprocessor.function_macro.vert:9:26: expected ;
FAILED(008): stringToDouble.vert:110:36: expected ,
FAILED(009): tokenPaste.vert:18:14: expected ;

FAILED 9 out of 161 files.

Just look for the files with the same names at the link above, the line:column points to the first error occurrence.

• (001): Does not escape a newline in a single-line comment;
• (002): ??? I'd be confused too 🥴, maybe the previous declaration already broke it?
• (003): Non-standard integer suffix as part of the extension;
• (004): Declaration in the while condition. Seems to be legal (see condition and iteration_statement rules);
• (005): Floating-point suffix Lf. Spec only allows f, F, lf, LF, but it's not marked as ERROR in the file. Not sure who's right;
• (006): Multiline comment in a #define 🤮;
• (007): Newline escape in a macro definition;
• (008): Same as (005);
• (009): Declaration substituted through a macro. If the parser does not keep track of macros, then, well...

Overall pretty clean, mostly newline escapes and (004) are relevant.

Duplicate hover hints for re-declared functions

Declaring the same function multiple times produces a hint for each declaration. Quite noticeable if you like to declare helper functions at the top and define them at the bottom.

#version 330 core

float foo(float, vec3);
float foo(float, vec3);

void main() {
    foo(1.0, vec3(1.0)); // <- triple hint
}

float foo(float, vec3) { return 1.0; }

Support `textDocument/rangeFormatting`

First, thank you for your work on this project, it's been a very helpful tool!

I'm using glsl_analyzer in Neovim, primarily for embedded glsl code blocks inside of other languages. For example, inside a TypeScript file:

// This is a test

const foo = "bar";

const vert = glsl`
  void main() {
    vec4 position = vec4(0.0, 0.0, 0.0, 1.0);
    gl_Position = position;
  }
`;

const hello = "world";

I'm using treesitter parsers for both TypeScript and GLSL. The TypeScript treesitter parser supports injected code blocks using tagged template literals as I've demonstrated above. Then, I'm using otter.nvim which lets you run LSPs on these embedded code blocks.

In this way, LSP autocompletion and hovering works perfectly. One drawback is that otter.nvim seems to need the attached LSP to support textDocument/rangeFormatting in order to format the code blocks, so I'm unable to use glsl_analyzer for formatting with my setup. Adding range formatting support should fix this.

Syntax highlighting question

What should we use for syntax highlighting with neovim? this lsp server doesn't seem to provide the syntax highlighting info

Run parse tests on larger code samples

There have been a few bad parser bugs recently, which could have been caught if we had more/larger test cases which exercised more parts of the code.

Formatting Options

I would like to be able to choose some options for the formatter. For example indentation and code style.

Known hover/completion bugs

I'll post newly found bugs for hover and completion in this issue to keep track of them until a testing suite that covers them is implemented with #26.

@nolanderc, please don't close the issue even if you fix the bugs mentioned here, as more can be discovered in the process.

Feel free to post too if you find any!

Completions should include `#define NAME ...`

References currently cannot point to the preprocessor tokens, since they are not included in the parse tree, but in a supplementary list. We should consider instead appending ignored tokens (comments and preprocessors) to the parse tree, after all the ordinary syntax nodes.

Neovim INVALID_SERVER_MESSAGE -32601

Hey mate,

Appreciate your work on this glsl lsp. I'm trying to set up for my neovim. This is my config which is a very standard set up:

lspconfig.glsl_analyzer.setup(coq.lsp_ensure_capabilities({
	on_attach = require("utils.handlers").on_attach,
	capabilities = require("utils.handlers").capabilities,
}))

But getting the "-32601" error code when I start neovim and the lsp is attached. It also shows up whenever I started to edit anything:

This happened when I opened the file:
neovim message

LSP[glsl_analyzer]: Error INVALID_SERVER_MESSAGE: {
  error = {
    code = -32601,
    message = "workspace/didChangeConfiguration"
  },
  jsonrpc = "2.0"
}
Press ENTER or type command to continue

~/.local/state/nvim/lsp.log

[START][2024-08-26 08:46:07] LSP logging initiated
[ERROR][2024-08-26 08:46:07] .../vim/lsp/rpc.lua:770    "rpc"   "/home/wpham/.nix-profile/bin/glsl_analyzer"    "stderr"        "debug: method: 'initialize'\n"
[ERROR][2024-08-26 08:46:07] .../vim/lsp/rpc.lua:770    "rpc"   "/home/wpham/.nix-profile/bin/glsl_analyzer"    "stderr"        "debug: method: 'initialized'\ndebug: method: 'workspace/didChangeConfiguration'\ndebug: method: 'textDocument/didOpen'\ndebug: opened: file:///home/wpham/learning/glsl/the_book_of_shaders/algorithmic_drawing/plot_line.frag : glsl : 0 : 539\n"
[ERROR][2024-08-26 08:46:07] ...m/lsp/client.lua:974    "LSP[glsl_analyzer]"    "on_error"      {  code = "INVALID_SERVER_MESSAGE",  err = {    error = {      code = -32601,      message = "workspace/didChangeConfiguration"    },    jsonrpc = "2.0"  }}

This happened when I edited the file:
neovim message

LSP[glsl_analyzer]: Error INVALID_SERVER_MESSAGE: {
  error = {
    code = -32601,
    message = "$/cancelRequest"
  },
  jsonrpc = "2.0"
}
Press ENTER or type command to continue

~/.local/state/nvim/lsp.log

[ERROR][2024-08-26 08:48:30] .../vim/lsp/rpc.lua:770    "rpc"   "/home/wpham/.nix-profile/bin/glsl_analyzer"    "stderr"        "debug: method: 'textDocument/didChange'\ndebug: didChange: file:///home/wpham/learning/glsl/the_book_of_shaders/algorithmic_drawing/plot_line.frag\ndebug: method: 'textDocument/documentColor'\ndebug: method: 'textDocument/didChange'\ndebug: didChange: file:///home/wpham/learning/glsl/the_book_of_shaders/algorithmic_drawing/plot_line.frag\ndebug: method: 'textDocument/documentColor'\n"
[ERROR][2024-08-26 08:48:31] .../vim/lsp/rpc.lua:770    "rpc"   "/home/wpham/.nix-profile/bin/glsl_analyzer"    "stderr"        "debug: method: 'textDocument/didChange'\ndebug: didChange: file:///home/wpham/learning/glsl/the_book_of_shaders/algorithmic_drawing/plot_line.frag\ndebug: method: 'textDocument/documentColor'\n"
[ERROR][2024-08-26 08:48:31] .../vim/lsp/rpc.lua:770    "rpc"   "/home/wpham/.nix-profile/bin/glsl_analyzer"    "stderr"        "debug: method: 'textDocument/completion'\n"
[ERROR][2024-08-26 08:48:31] .../vim/lsp/rpc.lua:770    "rpc"   "/home/wpham/.nix-profile/bin/glsl_analyzer"    "stderr"        "debug: complete: 19:3 file:///home/wpham/learning/glsl/the_book_of_shaders/algorithmic_drawing/plot_line.frag\n"
[ERROR][2024-08-26 08:48:32] .../vim/lsp/rpc.lua:770    "rpc"   "/home/wpham/.nix-profile/bin/glsl_analyzer"    "stderr"        "debug: method: 'textDocument/didChange'\ndebug: didChange: file:///home/wpham/learning/glsl/the_book_of_shaders/algorithmic_drawing/plot_line.frag\ndebug: method: 'textDocument/documentColor'\ndebug: method: 'textDocument/didChange'\ndebug: didChange: file:///home/wpham/learning/glsl/the_book_of_shaders/algorithmic_drawing/plot_line.frag\ndebug: method: 'textDocument/documentColor'\ndebug: method: 'textDocument/didChange'\ndebug: didChange: file:///home/wpham/learning/glsl/the_book_of_shaders/algorithmic_drawing/plot_line.frag\ndebug: method: 'textDocument/documentColor'\n"
[ERROR][2024-08-26 08:48:32] .../vim/lsp/rpc.lua:770    "rpc"   "/home/wpham/.nix-profile/bin/glsl_analyzer"    "stderr"        "debug: method: '$/cancelRequest'\n"
[ERROR][2024-08-26 08:48:32] ...m/lsp/client.lua:974    "LSP[glsl_analyzer]"    "on_error"      {  code = "INVALID_SERVER_MESSAGE",  err = {    error = {      code = -32601,      message = "$/cancelRequest"    },    jsonrpc = "2.0"  }}
[ERROR][2024-08-26 08:48:33] .../vim/lsp/rpc.lua:770    "rpc"   "/home/wpham/.nix-profile/bin/glsl_analyzer"    "stderr"        "debug: method: '$/cancelRequest'\n"
[ERROR][2024-08-26 08:48:33] ...m/lsp/client.lua:974    "LSP[glsl_analyzer]"    "on_error"      {  code = "INVALID_SERVER_MESSAGE",  err = {    error = {      code = -32601,      message = "$/cancelRequest"    },    jsonrpc = "2.0"  }}

Any thoughts?

Regression in v1.1.3 for hover on struct field declarations

Okay, now it seems that solving #23 broke hover for struct fields:

Rolled back to v1.1.2 and works fine there. The hover and autocomplete there just don't display anything.

(Can't reopen the old issue, since it wasn't me who closed it, so here's a new one.)

Bad formatting for `attribute` and `varying`

This code:

attribute vec4 color0;
varying vec4 color;
void main() {}

gets formated as:

attributevec4 color0;
varyingvec4 color;
void main() {}

src/parse.zig:236:65: error: @intCast must have a known result type

zig version
0.11.0

From the AUR I downloaded glsl_analyzer 1.4.2-1
This is the result of makepkg -si

==> Making package: glsl_analyzer 1.4.2-1 (Sat 27 Jan 2024 08:15:21 PM EST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found glsl_analyzer-1.4.2.tar.gz
==> Validating source files with sha256sums...
    glsl_analyzer-1.4.2.tar.gz ... Passed
==> Extracting sources...
  -> Extracting glsl_analyzer-1.4.2.tar.gz with bsdtar
==> Starting prepare()...
==> Removing existing $pkgdir/ directory...
==> Starting build()...
zig build-exe glsl_analyzer ReleaseSafe native-linux.5.15-gnu: error: the following command failed with 1 compilation errors:
/usr/bin/zig build-exe /home/red/aur/glsl_analyzer/src/glsl_analyzer-1.4.2/src/main.zig -lc -OReleaseSafe --cache-dir /home/red/aur/glsl_analyzer/src/glsl_analyzer-1.4.2/zig-cache --global-cache-dir /home/red/.cache/zig --name glsl_analyzer -target native-linux.5.15-gnu -mcpu x86_64 --mod glsl_spec.json.zlib::/home/red/aur/glsl_analyzer/src/glsl_analyzer-1.4.2/zig-cache/o/0d99a25104017fd8647c9c791387d7bc/spec.json.zlib --mod build_options::/home/red/aur/glsl_analyzer/src/glsl_analyzer-1.4.2/zig-cache/c/a7739f5d2e61771a7ece24220bb67000/options.zig --deps glsl_spec.json.zlib,build_options -L /usr/lib -I /usr/include --listen=- 
Build Summary: 2/5 steps succeeded; 1 failed (disable with --summary none)
install transitive failure
└─ install glsl_analyzer transitive failure
   └─ zig build-exe glsl_analyzer ReleaseSafe native-linux.5.15-gnu 1 errors
src/parse.zig:236:65: error: @intCast must have a known result type
            @memset(nodes.items(.parent)[span.start..span.end], @intCast(index));
                                                                ^~~~~~~~~~~~~~~
src/parse.zig:236:65: note: use @as to provide explicit result type
==> ERROR: A failure occurred in build().
    Aborting...

Include support on Windows

Great work on this project! I tried using it on windows and ran into this issue, I think the way paths are interpreted on windows is wrong and is leading to FileNotFound errors (in vscode):

#include "global.glsl"

#define INSTANCE_MASK_OPAQUE 0x01

void main () {}

debug: hover: 14:16 file:///c%3A/Users/dylan/dev/test/shader/gbuffer.glsl
debug: hover word: 'INSTANCE_MASK_OPAQUE'
error: could not open 'file:///c%3A/Users/dylan/dev/test/shader\\global.glsl': FileNotFound

Panics on Asahi Linux (Apple M1)

Just noting that I get the following panic on Asahi Linux (Apple M1):

thread 3047225 panic: reached unreachable code
Panicked during a panic. Aborting.
zsh: IOT instruction (core dumped)

Using v1.5.1's aarch64-linux-musl.zip

Parser crash in incomplete initializer lists

Hi, hope you're doing well!

Stumbled upon this during refactoring of some code, here's a repro:

#version 450 core

struct S {
    float value;
};

void main() {
    const S s = {
    const float dummy = 0.0;
}

Version v1.5.1. Below is the output from a dry --parse-file run, maybe that gives you a hint without having to test this yourself.

glsl_analyzer --parse-file src/shaders/test.glsl 
thread 9939 panic: parser ran out of fuel (infinite loop?): parse.Tag.keyword_const
/home/automatic/projects/glsl_analyzer/src/parse.zig:0:17: 0x109f54e in infixExpressionOptImpl (glsl_analyzer)
/home/automatic/projects/glsl_analyzer/src/parse.zig:1053:34: 0x1086acb in constantExpressionOpt (glsl_analyzer)
    return infixExpressionOptImpl(p, .eof);
                                 ^
/home/automatic/projects/glsl_analyzer/src/parse.zig:989:31: 0x1094cf9 in assignmentExpressionOpt (glsl_analyzer)
    if (!constantExpressionOpt(p)) return false;
                              ^
/home/automatic/projects/glsl_analyzer/src/parse.zig:984:33: 0x107d2e4 in initializer (glsl_analyzer)
    if (!assignmentExpressionOpt(p)) p.emitError("expected an expression");
                                ^
/home/automatic/projects/glsl_analyzer/src/parse.zig:720:24: 0x107d270 in initializer (glsl_analyzer)
            initializer(p);
                       ^
/home/automatic/projects/glsl_analyzer/src/parse.zig:943:34: 0x106099e in variableDeclarationSuffix (glsl_analyzer)
    if (p.eat(.@"=")) initializer(p);
                                 ^
/home/automatic/projects/glsl_analyzer/src/parse.zig:938:30: 0x1087391 in simpleStatement (glsl_analyzer)
    variableDeclarationSuffix(p, m_var);
                             ^
/home/automatic/projects/glsl_analyzer/src/parse.zig:879:41: 0x107cb51 in statement (glsl_analyzer)
            const kind = simpleStatement(p);
                                        ^
/home/automatic/projects/glsl_analyzer/src/parse.zig:752:22: 0x106078c in block (glsl_analyzer)
            statement(p);
                     ^
/home/automatic/projects/glsl_analyzer/src/parse.zig:697:26: 0x102c395 in parse (glsl_analyzer)
                    block(p);
                         ^
/home/automatic/projects/glsl_analyzer/src/main.zig:64:35: 0x1050bf5 in main (glsl_analyzer)
        var tree = try parse.parse(allocator, source, .{ .diagnostics = &diagnostics });
                                  ^
/opt/zig/zig-linux-x86_64-0.13.0/lib/std/start.zig:524:37: 0x1057ae5 in main (glsl_analyzer)
            const result = root.main() catch |err| {
                                    ^
../sysdeps/nptl/libc_start_call_main.h:58:16: 0x7f2a21423a8f in __libc_start_call_main (../sysdeps/x86/libc-start.c)
../csu/libc-start.c:360:3: 0x7f2a21423b48 in __libc_start_main_impl (../sysdeps/x86/libc-start.c)
???:?:?: 0x102a194 in ??? (???)
???:?:?: 0x0 in ??? (???)
Aborted (core dumped)

Parser crash in a `switch` statement

glsl_analyzer v1.0.8
glsl_analyzer-vscode v1.2.2

Hi, here's another snippet that crashes the parser:

#version 430 core

void main() {
    int i = 3;

    switch (i) {
        case 3:
            break;
        default:
            break;
    }

}

The output log:

[Error - 5:24:37 PM] Server process exited with signal SIGABRT.
[Info  - 5:24:37 PM] Connection to server got closed. Server will restart.
true
debug: method: 'initialize'
debug: method: 'initialized'
debug: method: 'textDocument/didOpen'
debug: opened: file:///home/automatic/projects/josh3d/src/shaders/test_switch.glsl : glsl : 100 : 146
debug: method: 'textDocument/hover'
debug: hover: 5:13 file:///home/automatic/projects/josh3d/src/shaders/test_switch.glsl
debug: hover word: 'i'
thread 1757103 panic: ran out of fuel
/opt/hostedtoolcache/zig/0.12.0-dev.790/x64/lib/std/debug.zig:373:22: 0x2ae14c in panicExtra__anon_18660 (glsl_analyzer)
/opt/hostedtoolcache/zig/0.12.0-dev.790/x64/lib/std/debug.zig:348:15: 0x2ada85 in panic__anon_17344 (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/parse.zig:0:0: 0x282c58 in statement (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/parse.zig:707:22: 0x27b078 in block (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/parse.zig:809:18: 0x28291e in statement (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/parse.zig:707:22: 0x27b078 in block (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/parse.zig:652:26: 0x236c99 in parseTree (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/Document.zig:133:38: 0x23bcdc in completionsAtPosition (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/main.zig:602:34: 0x23ee25 in textDocument/hover (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/main.zig:273:45: 0x24b62a in dispatchRequest (glsl_analyzer)
/home/runner/work/glsl_analyzer/glsl_analyzer/src/main.zig:247:59: 0x251958 in main (glsl_analyzer)
/opt/hostedtoolcache/zig/0.12.0-dev.790/x64/lib/std/start.zig:486:37: 0x253eba in main (glsl_analyzer)
/opt/hostedtoolcache/zig/0.12.0-dev.790/x64/lib/libc/musl/src/env/__libc_start_main.c:95:7: 0x2b0ae2 in libc_start_main_stage2 (/opt/hostedtoolcache/zig/0.12.0-dev.790/x64/lib/libc/musl/src/env/__libc_start_main.c)
Unwind error at address `exe:0x2b0ae2` (error.AddressOutOfRange), trace may be incomplete

[Error - 5:24:38 PM] Server process exited with signal SIGABRT.
[Error - 5:24:38 PM] The glsl_analyzer server crashed 5 times in the last 3 minutes. The server will not be restarted. See the output for more information.

[Feature] Support configuration of include search paths

Add the option to configure the include paths matching the -I option of GLSL compilers.

Preferably use the LSP workspace configuration and not command line arguments.

Variable declarations in global scope suggest to auto-complete themselves

Declaring a variable in local scope does not produce suggestions:

This is expected.

Variable declarations in global scope suggest to autocomplete to themselves:

It will keep suggesting itself as you type it out further. If the variable is declared for the first time, however, the self-suggestion does not appear until all other options have been rejected:

Not sure how much of an effort it would be to fix this, but since it works for locals, I'm hoping it's a simple change. Ideally, suggestions should not appear at all in declarations when typing them out, but it might be harder to get that right in the global scope.

Representation of function overloads in completions

Hey, I wanted to clarify one thing about the behavior of completion on overloads. Currently (v1.3.2), there's a duplicate entry for each function overload:

I think this is mostly noise and impacts discoverability. Could we maybe consolidate this into a single entry, since the documentation for each overload is still available through hover?

For reference, this is how clangd does this:

Where it says [N overloads] and provides docs for one of them. Now, clangd has full type information, so it can select the right overload on hover:

But it also supports signatureHelp (something that's worth considering for glsl_analyzer) to scroll through overloads:

For the current state of glsl_analyzer, I think it would help to remove duplicates in completions, but keep the documentation for each overload on hover, so that it's still accessible.

Once type information is available, we can also give the docs for the right overload on hover.
The signatureHelp could be added without type info for discoverability already, but it won't be able to show the "right/current" overload.

Bug (Neovim): Diagnostics not working

Diagnostics don't really work on Neovim. Completion, documentation and everything else works well, attached is my LSP logfile:
lsp.log

Setup with neovim

Hello, I am struggling with setting up glsl_analyzer with neovim.
I've followed the instructions in the README.md:
I installed it via source code and put the build directory in the PATH and this seems to work

I then added this in my neovim config:

-- glsl
require'lspconfig'.glsl_analyzer.setup{
    on_attach = function()
        print("attached")
    end
}

However this does not print "attached" when i open an .vert or .frag file and there is no syntax highlight or completion proposition other than from the buffer.

Does anyone know a solution to my problem ?
I am using:
Ubuntu 22.04.3 LTS
neovim: NVIM v0.10.0-dev-1412+g1094d0c0d

Bad hover hints for parameters in the interface blocks

glsl_analyzer v1.0.8

The hover hint seems to confuse the parameters between in and out interface blocks as the same variable if their names match.

The snippet:

#version 430 core


in Interface {
    vec2 tex_coords;
} in_[3];

out Interface {
    vec4 frag_pos;
    vec2 tex_coords;
} out_;


void main() {
    out_.tex_coords;
}

The hint I get:

Only show completions for extensions if enabled

We should look through all #extension directives and filter the completion list based on which extensions are enabled.