Skip to content
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

Parsing error for parameter calls with () #3603

Closed
1 task
devd opened this issue Jul 26, 2021 · 1 comment · Fixed by #3612
Closed
1 task

Parsing error for parameter calls with () #3603

devd opened this issue Jul 26, 2021 · 1 comment · Fixed by #3612
Assignees
Labels
bug Something isn't working lang:ruby parsing Requires a fix in a parser, typically a tree-sitter or menhir grammar.

Comments

@devd
Copy link

devd commented Jul 26, 2021

Describe the bug

Parse error on a ruby file that accepts block as a param and calls it via ->() and the pattern has metavariables.

To Reproduce
https://semgrep.dev/s/AwBL/

Expected behavior
no parse error

What is the priority of the bug to you?

  • P2: regular bug that should get fixed
@aryx aryx added the lang:ruby label Jul 26, 2021
@IagoAbal IagoAbal added bug Something isn't working parsing Requires a fix in a parser, typically a tree-sitter or menhir grammar. labels Jul 27, 2021
@IagoAbal
Copy link
Collaborator

This seems to be due to fake tokens in the Ruby AST.

@IagoAbal IagoAbal self-assigned this Jul 27, 2021
aryx added a commit to semgrep/pfff that referenced this issue Jul 27, 2021
aryx added a commit that referenced this issue Jul 27, 2021
This closes #3603

test plan:
test file included
IagoAbal added a commit that referenced this issue Jul 27, 2021
If we cannot get a range, instead of crashing, let's just log an error.

Helps #3603

test plan:
make test
aryx added a commit that referenced this issue Jul 27, 2021
* [Ruby] representing correctly a.(b) in the AST

This closes #3603

test plan:
test file included

* changelog
IagoAbal added a commit that referenced this issue Jul 30, 2021
Hopefully one day we can guarantee that every expression has a known
range. But, in the meantime, if we cannot get a range, we should handle
the situation more gracefully.

Let's remove Visitor_AST.range_of_any in favor of the safer
Visitor_AST.range_of_any_opt. This will force us to think what to do
in each situation where range info is not available. For now we just
log an error and move to something else.

Follows: #3603

test plan:
make test
aryx pushed a commit that referenced this issue Jul 30, 2021
Hopefully one day we can guarantee that every expression has a known
range. But, in the meantime, if we cannot get a range, we should handle
the situation more gracefully.

Let's remove Visitor_AST.range_of_any in favor of the safer
Visitor_AST.range_of_any_opt. This will force us to think what to do
in each situation where range info is not available. For now we just
log an error and move to something else.

Follows: #3603

test plan:
make test
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working lang:ruby parsing Requires a fix in a parser, typically a tree-sitter or menhir grammar.
Development

Successfully merging a pull request may close this issue.

3 participants