**Problem**
Currently operator_identifier includes characters
like colon at and equal even though they cannot be a legal
operator without backticks.
Having equal etc pushes tree-sitter into thinking some
construct to be an infix operation when they are `=`.
Another compilication is Unicode Math symbols,
which includes equal sign.
**Solution**
Remove colon, at, equal sign, and Math symbols from the
single-char operator_identifier.
This adds back back a few Math symbol unicodes.
Problem
-------
```scala
{ x =>
if (a) b.c }
```
is not parsed because OUTDENT token is not emitted in a presense of
space characters before the closing bracket
Solution
-------
Reorder space-handling and outdent-ing logic in external scanner
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`
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
-------
Unfortunately the smoke test hasn't been accurate.
Apparently it's been looking at only the top directories.
Solution
--------
This should fix it.
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.
Problem
-------
Current grammar accepts expression immeidately after `new`,
which is not correct, and doesn't work for Scala 3 syntax.
Solution
--------
This fixes it by actually using `$.template_body`.
It does create a tricky conflict between `new A: <block>`
construct and `new A: <type>`.
To deal with that, we are using `prec.dynamic`.
Problem
-------
The `identifier` token is hacked together, so we never quite get the
parsing right.
Solution
--------
My friend Ethan Atkins at some point experimented with generating
tree-sitter grammar out of EBNF (https://github.com/eatkins/tree-sitter-ebnf-generator/tree/master/examples/scala)
and his identifier, as far as I know is spec-correct.
We simplified the regex a bit to fit into the tree-sitter's unsigned
short int count, but it should be comparable.
Problem
-------
Currently operator-like identifiers are not part of the simple
expression, so you can't call `::(123)`.
Solution
--------
This includes `$.operator_identifier` into `_simple_expression`,
and further improves the expression hierarchy.
Note that this removes test on double-prefix-expression.
It's not allowed in Scala spec to have double-prefix.
Eugene Yokota
susliko
s.bazarsadaev
Ondra Pelech
Anton Sviridov