Duplicate Captures

[MixusMinimax]

Hi! I have already read through the other posts about this, and none of them seem to be like my case. I am using web-tree-sitter, and it gives me different results from what the rust CLI gives me during testing.

Source string:

module core::events;

Parse tree:

(source_file [0, 0] - [0, 20]
  (module [0, 0] - [0, 19]
    path: (path [0, 7] - [0, 19]
      (identifier [0, 7] - [0, 11])
      (identifier [0, 13] - [0, 19]))))

Query:

(source_file
  (module
    path: (path
      [
        (identifier) @namespace
        _
      ]*)))

The result using the rust cli:

examples/example-file
  pattern: 0
    capture: 0 - parent_path, start: (0, 7), end: (0, 11), text: `core`
    capture: 0 - parent_path, start: (0, 13), end: (0, 19), text: `events`

Result using web-tree-sitter:

queries.module.captures(tree.rootNode).map(s => s.node.text)
=> ['core', 'core', 'core', 'events', 'events', 'events']

// also, the node ids and capture names are the same within each group of three.

However, if I use .matches, it gives me one match with two captures, which is what I would expect.

Could this be a problem with web-tree-sitter or am I doing something wrong? All the other posts on here were missing an anchor or something, but I don't think this is the case here.

When using a quantifier (like * or +), that expression only matches consecutive elements. this is why I have the variant expression with the wildcard, to match things like comments or "::" nodes.

[MixusMinimax]

Intuitively, it would make sense if this expression matches subsets of a list of identifiers, but that is not the case for the CLI, which is why I was confused about the web-tree-sitter case.

Maybe using matches instead of captures is the right thing to do anyway? Now that I think about it in that way, that sounds reasonable.

[ahlinc]

Could you give a link to the grammar's repo if it's possible?

[MixusMinimax]

I have set up a minimal example here: gh:MixusMinimax/tree-sitter-test

You can see the relevant output in the 5th step "Run npm run-script test-node".

Edit: it seems like other people can't see the action logs. I will put the output here:

npm run-script test-node

Running example example1

Code:
module core::event;

Tree:
(source_file (module path: (path (identifier) (identifier))))

Captures:
{ index: 0, name: 'namespace', nodeId: 92872, text: 'core' }
{ index: 1, name: 'namespace', nodeId: 92872, text: 'core' }
{ index: 2, name: 'namespace', nodeId: 92872, text: 'core' }
{ index: 3, name: 'namespace', nodeId: 92616, text: 'event' }
{ index: 4, name: 'namespace', nodeId: 92616, text: 'event' }
{ index: 5, name: 'namespace', nodeId: 92616, text: 'event' }

Matches:
{
  index: 0,
  pattern: 0,
  captures: [
    { index: 0, name: 'namespace', nodeId: 92872, text: 'core' },
    { index: 1, name: 'namespace', nodeId: 92616, text: 'event' }
  ]
}

[ahlinc]

The result using the rust cli
Result using web-tree-sitter

Don't mix captures and matches modes, that was the main mistake.

Your original issue reproducible with CLI so it's not a bug in the web binding:

In the matches mode your original query works as you expected:

You need to properly construct your queries, on the bellow screenshot there are fixed queries for both captures and matches modes. Keep in mind that queries for the matches mode may not work well for the captures mode. Also be attentive when you use underscore placeholders, usually it's better to use explicit node names and especially for string literal terminals.

[MixusMinimax]

The reason why I used the variant and not your last example, is that if I for example have this string:

module core /**/   /**/  ::     /**/ // asdasd
events;

That query is not robust against extras in between nodes. I need to be able to query a list of identifiers, no matter how many other nodes are in between them.

But I think I understand how captures work a little better now, I guess just using matches instead is better.

But the captures query (where you do not use a quantifier) Works well. The only issue with that would be that it doesn't detect the difference between multiple module declarations or one with multiple path segments.

So I will use my original query, but not use the global captures list from now on. Thanks for your help!

My mistake was that I thought the CLI used captures per default, but it is of course now obvious to me that it is using matches mode.