bug: Parser Error in Array of SSBOs Declarations

[Xaldew]

Did you check existing issues?

• I have read all the tree-sitter docs if it relates to using the parser
• I have searched the existing issues

Tree-Sitter CLI Version, if relevant (output of tree-sitter --version)

tree-sitter 0.21.0

Describe the bug

I've been using this grammar for a bit to teach myself a bit about tree-sitter and to eventually create a (possibly) better GLSL major-mode for Emacs (glsl-mode). That said, I think I encountered a minor error in the current grammar as an array of SSBO buffers with an unbounded field (see below) seems to generate errors:

layout(binding = 1, set = 0, std430) buffer GBuffer { GBuffer g[]; } rgbuf[NFRAMES];

Changing the #define to a constant seems to help, but there is still errors in the output parse-tree, as seen below:

Steps To Reproduce/Bad Parse Tree

Parse tree included here:

(translation_unit [0, 0] - [14, 0]
  (comment [0, 0] - [0, 27])
  (preproc_call [1, 0] - [2, 0]
    directive: (preproc_directive [1, 0] - [1, 8])
    argument: (preproc_arg [1, 9] - [1, 12]))
  (preproc_def [3, 0] - [4, 0]
    name: (identifier [3, 8] - [3, 15])
    value: (preproc_arg [3, 16] - [3, 19]))
  (declaration [5, 0] - [5, 73]
    (layout_specification [5, 0] - [5, 36]
      (layout_qualifiers [5, 6] - [5, 36]
        (qualifier [5, 7] - [5, 18]
          (identifier [5, 7] - [5, 14])
          (number_literal [5, 17] - [5, 18]))
        (qualifier [5, 20] - [5, 27]
          (identifier [5, 20] - [5, 23])
          (number_literal [5, 26] - [5, 27]))
        (qualifier [5, 29] - [5, 35]
          (identifier [5, 29] - [5, 35]))))
    (identifier [5, 44] - [5, 48])
    (field_declaration_list [5, 49] - [5, 67]
      (field_declaration [5, 51] - [5, 65]
        type: (type_identifier [5, 51] - [5, 56])
        declarator: (array_declarator [5, 57] - [5, 64]
          declarator: (field_identifier [5, 57] - [5, 62]))))
    (identifier [5, 68] - [5, 72]))
  (declaration [6, 0] - [6, 84]
    (layout_specification [6, 0] - [6, 36]
      (layout_qualifiers [6, 6] - [6, 36]
        (qualifier [6, 7] - [6, 18]
          (identifier [6, 7] - [6, 14])
          (number_literal [6, 17] - [6, 18]))
        (qualifier [6, 20] - [6, 27]
          (identifier [6, 20] - [6, 23])
          (number_literal [6, 26] - [6, 27]))
        (qualifier [6, 29] - [6, 35]
          (identifier [6, 29] - [6, 35]))))
    (identifier [6, 44] - [6, 51])
    (field_declaration_list [6, 52] - [6, 68]
      (field_declaration [6, 54] - [6, 66]
        type: (type_identifier [6, 54] - [6, 61])
        declarator: (array_declarator [6, 62] - [6, 65]
          declarator: (field_identifier [6, 62] - [6, 63]))))
    (ERROR [6, 69] - [6, 75]
      (identifier [6, 69] - [6, 74]))
    (identifier [6, 75] - [6, 82])
    (ERROR [6, 82] - [6, 83]))
  (function_definition [9, 0] - [11, 1]
    type: (primitive_type [9, 0] - [9, 4])
    declarator: (function_declarator [9, 5] - [9, 11]
      declarator: (identifier [9, 5] - [9, 9])
      parameters: (parameter_list [9, 9] - [9, 11]))
    body: (compound_statement [10, 0] - [11, 1])))
../glsl-mode/bug.glsl	   0.34 ms	   715 bytes/ms	(ERROR [6, 69] - [6, 75])

Expected Behavior/Parse Tree

Not entirely sure what parse tree I should be expecting, it looks mostly correct
already, but I guess the ERROR expressions should be replaced with something
more appropriate, perhaps:

(declaration
  (layout_specification ...)
  (identifier)
  (field_declaration_list ...)
  (array_declarator declarator: (field_identifier) [ size: (identifier) ]))

Which seems similar to a regular array declaration.

Repro

Below is a shader that can reproduce this error with the current grammar:

#version 460

#define NFRAMES (2)

layout(binding = 0, set = 0, std430) buffer PRNG { uvec4 state[]; } prng;
layout(binding = 1, set = 0, std430) buffer GBuffer { GBuffer g[]; } rgbuf[NFRAMES];


void main()
{
}

[theHamsta]

Sorry for the long delay. Please let me know whether this is fixed now!

[Xaldew]

Hello! My turn to be sorry for the long delay, but yes, I'm pleased to say that it works just fine now!