C++ imports missed inside conditionals and expression_statement nodes

[HRV1527]

Hi, I’m using the C++ grammar with Tree-sitter to parse imports. I noticed two cases where imports seem to be missed:

1. Conditional includes:
   When a #include is nested inside #if or #ifdef, the node type is preproc_if / preproc_ifdef with preproc_include inside it. Currently, only top-level preproc_include is handled, so these conditionally compiled includes are skipped.

2. C++20 header-unit imports:
   Statements like import ; are parsed as an expression_statement containing a template_function.

Is this expected behavior ?
Or should we adjust our import traversal logic (e.g., descend into preproc_if and expression_statement) to catch these?

[vitali87]

Hi, I’m using the C++ grammar with Tree-sitter to parse imports. I noticed two cases where imports seem to be missed:

1. Conditional includes:
   When a #include is nested inside #if or #ifdef, the node type is preproc_if / preproc_ifdef with preproc_include inside it. Currently, only top-level preproc_include is handled, so these conditionally compiled includes are skipped.

2. C++20 header-unit imports:
   Statements like import ; are parsed as an expression_statement containing a template_function.

Is this expected behavior ?
Or should we adjust our import traversal logic (e.g., descend into preproc_if and expression_statement) to catch these?

Hey thanks for this observation. I would like to see some C++ experts to chime in and give feedback. Meanwhile I will research this myself to understand what the 'reasonable' expected behavior is.

[HRV1527]

My apologies for the confusion in my earlier response. The code is correct - since we're using Tree-sitter's capture method to retrieve nodes, it does indeed automatically traverse through the entire syntax tree, including all nested nodes. The capture mechanism searches for matching patterns at any depth within the tree, so nodes nested inside conditional preprocessor blocks (preproc_if/preproc_ifdef) or within expression statements should be found automatically.
I realize now that there wasn't actually an error in the implementation. The capture function's built-in traversal behavior should handle these nested cases without requiring any manual descent into child nodes.