Summary
-------
`$.lambda_expression` body was changed from `$._block` to
`$._indentable_expression`. This had the following effects:
* x10 faster parser generation
* parser size reduced from 41M to 24M
* conflict with `$.self_type`, which was resolved by matching
indent-tokens in `$.template_body`. This change, in its turn required
scanner.c to stop emitting INDENT and OUTDENT tokens when encountering
comments
Problem
-------
1. Repeat pattern with `*` doesn't parse.
2. Capture pattern `@` doesn't capture wildcard.
Solution
--------
1. This implements support for `*` in pattern.
2. This also allows using `_@`.
Summary
-------
Single line `$.comment` is split into a choice of `$._comment_text` and
`$.using_directive` to parse a structure of comments like
```
//> using scala 3.3.0
```
Problem
-------
Soft keywords ('open', 'end', 'infix', etc.) are not allowed to be used
as identifiers, e.g. in
```
open()
```
Solution
-------
Introduce `$._soft_identifier` with a lower precedence than modifiers
Problem
-------
Top-level expressions are not supported. However, it's a valid case for
Scala scripts or sbt configurations
Solution
-------
Now that AUTOMATIC_SEMICOLON tokens are handled at the top-level
enabling top-level expressions is done by including `$.expression` into
`$._top_level_definition`
Problem
-------
Compound type with refinement (structural type with a parent)
doesn't parse.
Solution
--------
This adds support for it.
It collides with context bounds `A: B: C`, so the precedence is set to
-1.
Problem
-------
Self-types are not parsed in braceless trait definitions:
```scala
trait A:
this: B =>
````
Solution
-------
Move existing `$.self_type` rule in trait definition into indented scope.
Rebalance `$.self_type` precedence.
Without explicit precedence it looses to `$.call_expression` in
```scala
trait A {
self: B =>
def f = ""
}
```
With static precedence instead of dynamic it leads to errors in
definitions like:
```scala
class A
x: Int // this should be $.ascription_expression
enum B:
case C
```
Problem
-------
`val` definitions with multiple identifiers are not supported.
Solution
--------
This implements `identifiers`, which acts like a pattern.
Problem
-------
Annotations on Scala 3 enums and their cases are not supported, e.g.
```scala
@A enum E:
@A("") @B case A
```
Solution
-------
Allow annotations in enum definitions
Problem
-------
Nested block comments are not parsed, e.g.
```
/* /* */ */
```
Solution
-------
Leave $.comment for single-line comments.
Introduce $.block_comment for block-comments.
Make $.block_comment out of several tokens to be able to detect nested
block comments
Problem
-------
By-name parameters in class definitions were not supported:
```
class A(a: => B)
```
Solution
-------
Support by-name parameters by changing the rule describing class
parameter type from `$._type` to `$._param_type`
Problem
-------
The grammar assumes upper type bound to go before lower type bound.
Although, in Scala it's the opposite:
```
TypeBounds ::= [‘>:’ Type] [‘<:’ Type]
```
Solution
-------
Swap type bounds' order in the grammar
Problem
-------
Catch-clause is not parsed when case is on the same line as 'catch':
```
try a catch b: C => d
```
Solution
-------
Intoduce `$._expr_case_clause` alternative to the catch-clause
Problem
-------
Scala 3 introduced using clauses to function call expressions:
```scala
f(using A)
```
The grammar did not allow that
Solution
-------
Add `choice` between regular and using-clause argument lists in
`$.arguments`
Problem
-------
Addition of optional `$.derives_clause` to the `$.class_definition` blowed its
states from ~500 to ~700 and doubled maximum memory usage during
generation. I've noticed, that the same addition of `$.derives_clause` to
the `$.object_definition` did not result in an increase of states. The
reason for this seems to be hidden in a separate rule
`$._object_definition`, that matches everything after the 'object' keyword
Solution
-------
Introduce `$._class_definition`, that matches everything after the
'class' keyword. This restrains the state machine blow when adding
support for `$.derives_clause`
Problem
-------
Derives clause is only defined for enums, but not for classes and
objects
Solution
-------
Include optional `$.derives_clause` in class and object definitions
Problem
-------
Guards in case clauses are thought to be lambda expressions sometimes,
e.g. in
```scala
{case a if b => c}
```
This happens, because `$.lambda_expression` has a higher parsing
precedence than `$._simple_expression`
Solution
-------
Avoid using numeric parsing precedence for `$.lambda_expression`.
Resolve specific conflicts instead
Problem
-------
`$.parameters` required each param to have a name, so `using` clauses like
`def x(using X =:= X)` failed to parse
Solution
-------
Introduce `$._using_parameters_clause`, which allows anonymous parameters
Problem
-------
Currently pattern match with guard doesn't parse.
Solution
--------
This implements it by creating an intermediate node called `_case_pattern` with right associativity.
_The problem_
Currently when you come across string interpolation you don't get any
special highlighting for the actual interpolator meaning:
```scala
ivy"com.lihaoyi::os-lib:0.9.0"
```
I all colored the same.
_The Solution_
The pr makes 2 changes.
- The `identifier` we use for the interpolator now becomes a field for
no reason other than I thought it'd be nice to just give it a name
- A hightlight query that captures it and assigns it to `function.call`.
Problem
-------
1. class constructor should accept annotation, but it doesn't.
2. Apparently Scala 3 does allow zero, one, or multiple parameter list
to an annotation, and differentiated between the class parameter by
its lack of type ascription.
Solution
--------
1. Add optional annotation for constructor. At this point, we can at
least parse the code with annotation on the ctor.
2. Unfortunatley, however, tree-sitter doesn't make enough lookahead to
distinguish postfix expr or ascription expression `(x: Int)`,
for now the class parameters will end up being parsed as arguments to
the annotation.
Problem
-------
1. In Scala 3, extends clause can be comma separated.
2. In Scala 2 or 3 extends clause can ctor with parameters:
`class D with E(x) with F(y)`.
Solution
--------
`extends` is now followed by *constructor applications* separated by
either `with` or `,` as opposed to treating them as a compound type.
Problem
-------
1. Currently `//` ends up matching `operator_identier`
2. There's also a bug in regex.
Solution
--------
1. Implement a workaround to avoid `//`.
2. Escape `-`, copying from the identifier regex.
Fixes https://github.com/tree-sitter/tree-sitter-scala/issues/127
Problem
-------
Currently our grammar does not support the fewer braces syntax,
which basically lets us pass the last argument as a block after `:`.
Solution
--------
This implements fewer braces support for call_expression,
infix_expression, with and without the lambda start.
susliko
GitHub
Eugene Yokota
ghostbuster91
Anton Sviridov
Chris Kipp