Open wenkokke opened 10 months ago
I'm working on something for this, should be ready in a week or two
I'm working on something for this, should be ready in a week or two
Wow, that was a quick response. Amazing!
@tek Do you know why it happens?
Wow, that was a quick response. Amazing!
😅 I happened to refresh the notifications page right when you posted
@tek Do you know why it happens?
Because there are many declared conflicts in the grammar, which causes tree-sitter to run two (or more) parallel attempts at parsing a sequence, one of which doesn't contain the _layout_semicolon
symbol that that scanner emits when indent should force a new decl.
The choice is then made based on dynamic precedence scores, which aren't well balanced in the grammar (and a bit mysterious).
@tek Any updates on this?
still a lot of work to do to get this to release, but I've got a week off so the chances are good 😁
any suggestions for workarounds I could use in the meantime?
other than using explicit semicolons, don't think it's that simple 😕
my current idea for a workaround is to fork and remove splices entirely, and use that fork in the meantime
oh, you could try giving the top_splice
rule a penalty:
top_splice: $ => prec.dynamic(-100, $._exp_infix),
not sure if that isn't too late in the reduction chain though.
@wenkokke prerelease for you to testdrive: https://github.com/tek/tree-sitter-haskell
As of vscode-parse-tree version 0.31.0, we are now shipping with tree-sitter-haskell version https://github.com/tree-sitter/tree-sitter-haskell/commit/a50070d5bb5bd5c1281740a6102ecf1f4b0c4f19, which I believe should include the fix, but @tek lmk if I'm wrong.
Fwiw here is the parse I get for the code snippet at the top of this issue:
(haskell
declarations: (declarations
(signature
name: (variable)
"::"
type: (function
parameter: (variable)
arrow: "->"
result: (variable)
)
)
(function
name: (variable)
patterns: (patterns
(variable)
)
match: (match
"="
expression: (variable)
)
)
(function
name: (variable)
patterns: (patterns
(variable)
(variable)
)
match: (match
"="
expression: (variable)
)
)
(signature
name: (variable)
"::"
type: (function
parameter: (name)
arrow: "->"
result: (name)
)
)
(function
name: (variable)
patterns: (patterns
(literal
(integer)
)
)
match: (match
"="
expression: (literal
(integer)
)
)
)
(function
name: (variable)
patterns: (patterns
(literal
(integer)
)
)
match: (match
"="
expression: (literal
(integer)
)
)
)
(function
name: (variable)
patterns: (patterns
(variable)
)
match: (match
"="
expression: (infix
left_operand: (apply
function: (variable)
argument: (parens
"("
expression: (infix
left_operand: (variable)
operator: (operator)
right_operand: (literal
(integer)
)
)
")"
)
)
operator: (operator)
right_operand: (apply
function: (variable)
argument: (parens
"("
expression: (infix
left_operand: (variable)
operator: (operator)
right_operand: (literal
(integer)
)
)
")"
)
)
)
)
)
)
)
@wenkokke I believe you were seeing failures only when running tests on your cursorless haskell branch? I haven't tried this new version there so can't verify whether the fix has worked
yep this should be resolved
The following piece of Haskell code is SOMETIMES incorrectly parsed as containing a series of top-level splices.
Specifically, the common parse is as follows:
However, in some circumstances it is parsed to the following very incorrect syntax tree:
This bug is showing up in the test suite for the Haskell support for cursorless-dev/cursorless, and @pokey and I are working to determine exactly when the bug shows up. However, even if we cannot nail down exactly when the bug shows up, it might be worthwhile ruling the second parse out entirely. Perhaps by anchoring top-level function definitions to the first column, or forcing a line-break after a top-level splice?