Problem
-------
The following comment combinations are not parsed:
1. ```
// /*
// *
// */
```
2. ```
/* // */
```
Solution
-------
- set higher lexing priority for `$._comment_text` token
- include "//" as an alternative to the contents of `$.block_comment`
Problem
-------
Structural types in declarations are not parsed:
```
val x: F { val y: Int }
```
Solution
-------
Remove -1 precedence for `$._structural_type` branch of `$.compount_type`, resolve conflict with `$._type` explicitly
Extra changes
-------
Removed some unused conflict resolutions
Problem
-------
Parameter lists spreading multiple lines are not handled:
```
class A
():
def b
(): Int = 1
```
Solution
-------
Match `$._automatic_semicolon` in `$._function_constructor` and
`$.class_parameters`
Side-change: reuse `$._function_declaration` in `$.function_definition`
Problem
-------
Definitions like the following are not supported:
```scala
val a,b,c: Int = 1
var d,e = ""
```
Solution
-------
Add `$.identifiers` as a choice option along with `$._pattern` to
`$.var_definition`.
Remove `prec(-1)` in `$.identifiers` definitions so that parser wouldn't
on declarations with more than two identifiers.
Resolve a conflict between `$.identifiers` and `$.val_declaration`
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.
Johannes Coetzee
Karan Ahlawat
s.bazarsadaev
susliko
GitHub
eugene yokota
ghostbuster91
Anton Sviridov