There's an issue with parsing match statements at the moment in this specific case of match + pass:
func _transition_to_state(new_state):
match previous_state:
pass
That messes with the formatter because it produces an ERROR token whose id resolves to 65k (max uint 16 bits, indicates no id in tree sitter). Causes a panic.
The formatter should decide on what to do with cases where there are errors in the output. Often the error is going to be localized to one statement, but it could bubble up or be potentially anywhere the user makes an actual syntax error.
The GDScript parser we use and the logic of the formatter can be lenient and could still format despite the file having one or more errors.
I see at least three options for handling errors:
- Simplest: refuse to format a file with any parse errors. But that's not very satisfying for the end user. What if there's an unsupported piece of syntax in a 3000 line script?
- Try to format around the ERROR. I'm not sure this can work because the error could be anywhere and it messes the AST to the point where the formatter could completely misunderstand the code.
- Walk to the parent of the error AST node and output this entire branch as unformatted output.
Second option, I think it could easily go wrong so I would explore it last.
Third option I'm not 100% sure about the reliability of walking up to the parent block, or if we should walk up to an entire function, for example (or more generally a parent declaration). I think grabbing the parent block and making it go through the same logic as the code that turns the formatter off and on should be enough. But this needs confirmation.
There's an issue with parsing match statements at the moment in this specific case of match + pass:
That messes with the formatter because it produces an ERROR token whose id resolves to 65k (max uint 16 bits, indicates no id in tree sitter). Causes a panic.
The formatter should decide on what to do with cases where there are errors in the output. Often the error is going to be localized to one statement, but it could bubble up or be potentially anywhere the user makes an actual syntax error.
The GDScript parser we use and the logic of the formatter can be lenient and could still format despite the file having one or more errors.
I see at least three options for handling errors:
Second option, I think it could easily go wrong so I would explore it last.
Third option I'm not 100% sure about the reliability of walking up to the parent block, or if we should walk up to an entire function, for example (or more generally a parent declaration). I think grabbing the parent block and making it go through the same logic as the code that turns the formatter off and on should be enough. But this needs confirmation.