bug: Incorrect parsing on function typedef

[NathanSnail]

Did you check existing issues?

• [ ] I have read all the tree-sitter docs if it relates to using the parser
• [X] I have searched the existing issues of tree-sitter-c

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

No response

Describe the bug

Using

int typedef fn_typdef(const char *args);

like syntax to define a function typedef results in the typedef keyword being highlighted as a variable and an error in the syntax tree. :Inspect in neovim :InspectTree This syntax is relatively obscure but is valid and so should be highlighted correctly.

Steps To Reproduce/Bad Parse Tree

1. Make a file which uses function typedef syntax ReturnT typdef TypeName(args);
2. Now the typedef will by incorrectly represented in the tree.

Expected Behavior/Parse Tree

The tree should probably use keyword.type.c like it usually does for typedefs.

Repro

// Example code that causes the issue
int typedef fn_typdef(const char *args);

[narpfel]

This does not only affect function types but all typedefs where the typedef token is not the first token in the declaration:

$ cat t.c
int typedef U;
$ tree-sitter parse t.c
(translation_unit [0, 0] - [1, 0]
  (declaration [0, 0] - [0, 14]
    type: (primitive_type [0, 0] - [0, 3])
    declarator: (identifier [0, 4] - [0, 11])
    (ERROR [0, 12] - [0, 13]
      (identifier [0, 12] - [0, 13]))))
t.c     Parse:    0.16 ms           93 bytes/ms (ERROR [0, 12] - [0, 13])

[gr1mpatr0n]

Woah, this is definitely a TIL! Never seen this syntax in 10 years of C programming. Is there any benefit/difference to it?

[narpfel]

Is there any benefit/difference to it?

No, it’s just another case where C’s grammar is unnecessarily weird and complex. Apart from writing test cases for a C compiler, this should IMHO never be used.