Skip to content

bug: Parse error with function annotations #310

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
2 tasks done
alexle0nte opened this issue Mar 27, 2025 · 1 comment
Open
2 tasks done

bug: Parse error with function annotations #310

alexle0nte opened this issue Mar 27, 2025 · 1 comment
Labels

Comments

@alexle0nte
Copy link

alexle0nte commented Mar 27, 2025

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 of tree-sitter-cpp

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

tree-sitter 0.25.3 (2a835ee029dca1c325e6f1c01dbce40396f6123e)

Describe the bug

When parsing code that uses function annotations, the parse tree incorrectly reports an ERROR node.
For example, given the following snippet that contains a function annotated with EXPORT:

#define EXPORT __attribute__((visibility("default")))

EXPORT
void foo() {}

The following error appears in the parse tree: (ERROR [3, 0] - [3, 4].

Steps To Reproduce/Bad Parse Tree

  1. Write the code above in a C++ file.
  2. Run tree-sitter parse on the file.
  3. Observe the obtained parse tree:
(translation_unit [0, 0] - [4, 0]
  (preproc_def [0, 0] - [1, 0]
    name: (identifier [0, 8] - [0, 14])
    value: (preproc_arg [0, 15] - [0, 53]))
  (function_definition [2, 0] - [3, 13]
    type: (type_identifier [2, 0] - [2, 6])
    (ERROR [3, 0] - [3, 4]
      (identifier [3, 0] - [3, 4]))
    declarator: (function_declarator [3, 5] - [3, 10]
      declarator: (identifier [3, 5] - [3, 8])
      parameters: (parameter_list [3, 8] - [3, 10]))
    body: (compound_statement [3, 11] - [3, 13])))

Expected Behavior/Parse Tree

The parse tree should not have errors.

Repro

#define EXPORT __attribute__((visibility("default")))

EXPORT
void foo() {}
@eezstreet
Copy link

I would think that this is not an issue with the tree-sitter grammar, because the grammar only describes a well-formed piece of source code. Because there is preprocessing required to yield well-formed source code here, there is no issue.

The correct course of action would be to take this code:

#define EXPORT __attribute__((visibility("default")))

EXPORT
void foo() {}

And do a substitution of the preprocessor macro:

#define EXPORT __attribute__((visibility("default")))

__attribute__((visibility("default")))
void foo() {}

If that yields an error, then there is a problem. At least in my humble opinion anyway. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants