value field of declaration node is required in node-types.json but does not exist in parse tree

It is said that value field of declaration node is required in node-types.json. The following code is related part of node-types.json.

  {
    "type": "declaration",
    "named": true,
    "fields": {
      .....
      "value": {
        "multiple": false,
        "required": true,
        "types": [
          {
            "type": "_expression",
            "named": true
          },
          {
            "type": "initializer_list",
            "named": true
          }
        ]
      },
      .....
    },

However, value field of declaration node does not exist in the parse tree generated by tree sitter. The parse tree of source code int func(); is,

declaration:
   children: [ 
     primitive_tive,
     function_declarator,
    ;
  ]
  ...

The field name of primitive_tive child node is type and field name of function_declarator child node is declarator. However, there is no child node with value field name.

[maxbrunsfeld]

Ok, a couple of answers:

1. The default_value field was already correct. The operator_cast_declaration has an optional default_value field, and as @CamilleTeruel points out, the operator_cast_declaration is aliased as a declaration in the grammar.

   This means that at runtime, a syntax node of type declaration may have been generated by the operator_cast_declaration rule, so it can optionally have a default_value field.

2. The value field was not correct. It should indeed be present for a similar reason as default_value, but it should have required set to false. The required flag was being computed incorrectly due to a bug in Tree-sitter, which is now fixed in commit https://github.com/tree-sitter/tree-sitter/commit/9d182bb0785f158ba5b6ab14df8fae0eff8aa819. I am publishing a new release of the Tree-sitter CLI and then I will regenerate the node-types.

[CamilleTeruel]

Thanks for the fix @maxbrunsfeld, that was fast!

This means that at runtime, a syntax node of type declaration may have been generated by the operator_cast_declaration rule, so it can optionally have a default_value field.

Oh I see, I was interpreting the aliasing feature the wrong way 😄 (operator_cast_declaration nodes with the same fields than declaration plus extra ones).

Also, just curious - are you folks able to share what you’re using the node-types.json for? I’m curious what language you are using Tree-sitter from, and how well it is working to use the node types. We have only really used it from Haskell, and it took a bit of effort to get it to work nicely.

Sure, we use tree-sitter from python. We use node-type.json to generate:

• a hierarchy of classes for each parse tree node type,
• a type-directed traversal of parse trees. It is then used to transform parse trees into language-agnostic ASTs via a term rewriting library. We use those ASTs to perform various analyses.

I guess it is somewhat similar to what haskell-tree-sitter/semantic are doing.