Pattern matching

[aibaars]

This pull request adds pattern matching syntax to the Ruby grammar. This syntax looks as follows:

case expr
  in pattern1 then  ...
  in pattern2 then ...
  else ...
end

See also: https://docs.ruby-lang.org/en/3.0.0/doc/syntax/pattern_matching_rdoc.html

This pull request does not yet add the one-line pattern matching syntax (expr in pattern and expr => pattern). While the addition to the grammar just a few lines, it causes a serious increase in the generated C code. Therefore, I think this is best left as a follow-up pull request where we can discuss what causes the blow-up and how to address it. See also: aibaars#1

This pull request makes some minor changes to the existing grammar:

• _expression is added to the supertypes list to avoid a lot of duplication in the node-types file
• A new intermediate rule _literal is extracted for the various types of literals allowing it to be used for expressions as well as patterns.
• The unary literal rule only allowed float and integer values, this has been corrected to also allow the other numeric literals (e.g. complex and rational)

Checklist:

• All tests pass in CI.
• There are sufficient tests for the new fix/feature.
• Grammar rules have not been renamed unless absolutely necessary.
• The conflicts section hasn't grown too much.
• The parser size hasn't grown too much (check the value of STATE_COUNT in src/parser.c).

[dcreager]

This looks good, thanks @aibaars! Do the syntax highlighting queries need to be updated to highlight patterns correctly?

[aibaars]

This looks good, thanks @aibaars! Do the syntax highlighting queries need to be updated to highlight patterns correctly?

@dcreager Possibly, but I don't know how to check that. I suspect that things might "just work" already because the pattern syntax is quite similar to expressions and re-uses the same keywords.

[dcreager]

The easiest way would be to run tree-sitter highlight against some Ruby files containing patterns and make sure they look "right". You can also add some additional tests to the tests/highlight directory if you wanted to verify it more rigorously (and in a way that would prevent regressions).

[aibaars]

@dcreager Ideally the highlight of ** would be none, however, I don't know how to express that.

[dcreager]

Hmm, I actually don't know if that can be done! That's an interesting thing that we should support. 👍 with this workaround for now.

[dcreager]

Hmm, I actually don't know if that can be done! That's an interesting thing that we should support. 👍 with this workaround for now.