Gleam 0.23.3 allows discarding imported modules with the discard syntax.
This needs a small change in tree-sitter-gleam to accept discard nodes
in the import's 'as' field.
This was 'soft-removed' in the past by removing the highlights and test
cases but we held off on fully removing the parser support. This
finishes the job so that 'try' is no longer treated as a keyword.
This should fix the integration tests. Previously they would fail
against some code in the stdlib which used 'try' as a regular variable
name.
This improvement was mentioned in the v0.31.0 release notes. This is
already supported so all I've done is remove the comment about how the
behavior does not yet exist upstream and add a test case.
Previously the 'use' node would have many 'identifier' or pattern nodes
and, with the parent commit, types as well. This change should make it
easier to figure out which children nodes of 'use' are associated with
one another.
Co-authored-by: Jonathan Arnett <jonarnett90@gmail.com>
This makes me a little uneasy, as the way that the Gleam parser parses
"let assert" is that it first parses "let", then calls
"parse_assignment" which will look to see if an "assert" comes next,
and uses this information to choose the node type.
I think a closer tree-sitter implementation would look like this:
_statement: ($) => choice($._expression, $._assignment, $.use),
...
_assignment: ($) => choice($.let, $.let_assert),
let: ($) => seq("let", $._assignment2),
let_assert: ($) => seq("let", "assert", $._assignment2)
_assignment2: ($) =>
...
However this requires an awkward "_assignment2" and isn't
substantially closer to the Gleam parser to warrant the change.
Also we could simply do `optional("assert")`, but that would make
"let" and "let assert" the same node type, which I suspect is an anti-feature.
With the latest changes to the gleam parser, code that uses let/use as
expressions is now rejected. This change reorganizes let and use under
a new '_statement' rule. This restricts let/use from taking other
let/use statements since they only accept expressions.
floats may have a trailing dot with no trailing digits, like in
the float stdlib module:
pub fn absolute_value(x: Float) -> Float {
case x >=. 0. {
True -> x
_ -> 0. -. x
}
}
Nodes defined in `extras` can be expected before an node. Thus, `comment` could be expected before `escape_sequence` or `quoted_content`; aka inside of a string. Naturally, this makes no sense.
I tried wrapping `escape_sequence` and `quoted_content` in `token.immediate` to resolve the issue, but it had no effect (maybe is specific to whitespace?). Instead, I found success in largely copying [`tree-sitter-rust`'s solution of using an external scanner for string content](9a6d980afb/src/scanner.c (L27-L40)).
* parse top-level expressions
This change allows the parser to return valid nodes for expressions
on the "top-level" of a document.
Here "top-level" is read as "not within a function." This is actually
invalid Gleam code: for example, you cannot write a `case/2` statement
outside of a function body. This is desirable for the tree-sitter
parser, though, because the parser will end up being used in flexible
situations, such as one-off highlights in fenced markdown blocks, e.g.:
```gleam
<<code:int-size(8)-unit(2), reason:utf8>>
```
Which is a common usage in an editor, or on GitHub.
* remove test cases for invalid syntax
closes#17
This refactor brings this grammar more in line with tree-sitter-rust.
A function or type declaration may have a visibility modifier ("pub") and
type declarations may also have an opacity modifier ("opaque"). This ends
up reducing the number of named rules, which cleans up the queries a bit.