Skip to content

fix: identifiers in collection expressions vs attributes with targets#4

Merged
maciejpirog merged 1 commit intoopengrep/mainfrom
fix-idents-in-collection-exprs-vs-attribute-targets
Jan 14, 2026
Merged

fix: identifiers in collection expressions vs attributes with targets#4
maciejpirog merged 1 commit intoopengrep/mainfrom
fix-idents-in-collection-exprs-vs-attribute-targets

Conversation

@maciejpirog
Copy link
Collaborator

Fix a bug (seems to be in the original tree-sitter parser):

The parser confused collection expression that started with an identifier similar to an attribute target, e.g., [type, ...] etc with attributes with targets [type: ...].

Comment on lines +230 to +231
| `Fiel tok -> R.Case ("Fiel",
(* "field:" *) token env tok
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is R.Case ("Fiel" intentional?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vs R.Case ("Field"

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's autogenerated. No idea

* Token.t (* ":" *)
)
type attribute_target_specifier = [
`Fiel of Token.t (* "field:" *)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any reason for the renaming?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as above

| `Meth tok -> R.Case ("Meth",
(* "method:" *) token env tok
)
| `Para tok -> R.Case ("Para",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally liked Param, Ret and Field better... more readable.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as above

attribute_target_specifier: $ => seq(
choice('field', 'event', 'method', 'param', 'property', 'return', 'type'),
':'
choice('field:', 'event:', 'method:', 'param:', 'property:', 'return:', 'type:'),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not proficient enough in TS to appreciate this change, could we not have wrapped the original production in token(...) ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope. token parses as usual, but sticks things together only after they are parsed (I think), which would make TS go into wrong branch anyway. It would be better to have a more sensible structure of the grammar, but I tried to refactor for this PR and failed...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would work, if not a prec would help?

Anyway not important.

@maciejpirog maciejpirog merged commit 74fbff2 into opengrep/main Jan 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants