tree-sitter / tree-sitter-ruby

Ruby grammar for tree-sitter
MIT License
182 stars 58 forks source link

Ruby `...` (triple-dot) syntax not properly handled #237

Open lindluni opened 1 year ago

lindluni commented 1 year ago

While working on updating our usage of CodeQL we are seeing extraction errors on two files. Both say there are syntax errors in the file, but neither present with syntax issues when checked with ruby -c or with rubocop. One of them is being flagged on a Ruby construct, the ... operator, that has existed since Ruby 2.6. Any thoughts on why we are flagging these as syntax errors during extraction, but ruby itself is saying the files are valid, these are the two files:

And this is the error we are seeing:

Analysis produced the following diagnostic data:

|          Diagnostic          |       Summary        |
+------------------------------+----------------------+
| Extraction errors            | 2 results (2 errors) |
| Successfully extracted files | 4701 results         |

Diagnostic 'Extraction errors' (rb/diagnostics/extraction-errors) produced the following messages:
  * Error: Extraction failed in /home/runner/work/vets-api-clone-1/vets-api-clone-1/app/workers/sign_in/delete_expired_sessions_job.rb with error A parse error occurred (expected ; symbol). Check the syntax of the file. If the file is invalid, correct the error or exclude the file from analysis.
  * Error: Extraction failed in /home/runner/work/vets-api-clone-1/vets-api-clone-1/modules/forms_api/app/controllers/forms_api/v1/uploads_controller.rb with error A parse error occurred. Check the syntax of the file. If the file is invalid, correct the error or exclude the file from analysis.
aibaars commented 1 year ago

The problem in uploads_controller.rb can be reduced to the following and seems to be caused by the trailing key: parameter without value. The parser somehow expects a value or a ; even though the value is optional.

begin
  key = 10
  foo key:
rescue => e
end

The problem in delete_expired_sessions_job.rb can be reduced to the following and seems to be caused by the parser interpreting ... as forward parameters as if the code was written like def foo ... 3 end.

def foo
  ... 3
end