4 ms·
The thing is, for IDE purposes “production ready” has a different definition. The thing shouldn’t have 100% parity with the compiler, it should be close enough
by matklad 5y ago
The thing is, for IDE purposes “production ready” has a different definition. The thing shouldn’t have 100% parity with the compiler, it should be close enough to be useful, and it must be resilient. This is definitely not trivial, but is totally within the reach of a single person.
> And this doesn't even count error recovery / dealing with broken code ...
With a hand written parser, you mostly get error resilience for free. In rust-analyzer’s parser, there’s very little code which explicitly deals with recovery. The trick, is, during recursive descent, to just not bail on the first error.
- jhck 5y agoThose are some very nice insights, thanks for sharing them! Can you recommend a good resource on writing a parser by hand that doesn't bail on the first error? Or would you instead suggest studying the source code for e.g. the rust-analyzer parser?
- dunham 5y agoI can't answer this well and don't know of any resources, but I have seen it before in the parser for sixten: https://github.com/ollef/sixten/blob/60d46eee20abd62599badea85774a9365c81af45/src/Frontend/Parse.hs#L458 In that case, they're parsing a haskell-like language and can use indentation as a guide for how far to skip ahead. In a C-like language, I'd imagine you'd use braces or semicolons to see how far to skip ahead - the error bubbles up to a parser that knows how to recover, like say a statement or function body, it scans ahead to where it thinks its node ends and returns an error node, allowing the parent to continue.
- matklad 5y agoI don’t have a good resource, but https://m.youtube.com/watch?v=0HlrqwLjCxA https://m.youtube.com/watch?v=0HlrqwLjCxA is probably an OK start.
- jhck 5y agoThanks a lot, I'll give it a watch! Also, thanks dunham for the sixten suggestion!