tree-sitter-haskell
tree-sitter-haskell copied to clipboard
Instance with associated type, following TH top level splice, misparsed as function
I have done a run of executing tree-sitter-haskell against my employer Mercury's (closed source) codebase (350k LOC) and found a few parser bugs, which I have committed simplified testcases for on https://github.com/lf-/tree-sitter-haskell/tree/top-level-splices-oopsie. I am going to try to fix the ones that I think I can fix over the next few weeks.
I'm filing this incorrect parse as a bug because I am baffled by it and don't know how to fix it. My best guess is that for some reason the function parser gets greedy and ignores the semicolons?
The following test case misparses as a function
node. Notably, if the instance
is changed to have an associated value or such, it will parse correctly.
================================================================================
template haskell: top level splice without parens, but weird
================================================================================
someTemplateHaskell $(spliceOne)
instance SomeClass Something where
type Assoc Something = ()
---
AST:
(haskell [0, 0] - [4, 0]
(function [0, 0] - [3, 27]
name: (variable [0, 0] - [0, 19])
patterns: (patterns [0, 20] - [3, 22]
(splice [0, 20] - [0, 32]
(exp_parens [0, 21] - [0, 32]
(exp_name [0, 22] - [0, 31]
(variable [0, 22] - [0, 31]))))
(pat_name [2, 0] - [2, 8]
(variable [2, 0] - [2, 8]))
(pat_name [2, 9] - [2, 18]
(constructor [2, 9] - [2, 18]))
(pat_name [2, 19] - [2, 28]
(constructor [2, 19] - [2, 28]))
(pat_name [2, 29] - [2, 34]
(variable [2, 29] - [2, 34]))
(pat_name [3, 2] - [3, 6]
(variable [3, 2] - [3, 6]))
(pat_name [3, 7] - [3, 12]
(constructor [3, 7] - [3, 12]))
(pat_name [3, 13] - [3, 22]
(constructor [3, 13] - [3, 22])))
rhs: (exp_literal [3, 25] - [3, 27]
(con_unit [3, 25] - [3, 27]))))
awesome!
I don't intend to fix this bug as I'm just too lost on it, so it's fair game if you want to pick it up some time.
(this is not high priority at all though; it affects one file total for me, and is easily worked around by some slight rearrangement or using explicit toplevel splices)