-
Notifications
You must be signed in to change notification settings - Fork 0
Description
So the current parser of the plugin is 💩 and I don't want to invest any more time and tokens into it. It just doesn't make sense. The parser grilling technique that sounded like a practical approach to me ended up being very ineffective - the agentic loop wasn't as tightly closed as it was needed, agents weren't able to reliably validate the resulting PSI.
Our lexer should be pretty fine, though! No need to replace that part.
My current idea is to create a brand-new parser and PSI structure, that is just a rip-off https://github.com/elixir-tools/spitfire. At the time of writing this issue, Spitfire is still struggling with some parsing errors, but the Expert team is fighting with them right now and things should settle down in incoming weeks.
When this will be done, we can take Spitfire and use LLMs to port it into IntelliJ framework, completely bypassing Grammar-Kit!
The order of operations should be roughly:
- Take Spitfire AST/CST and model 1:1 PSI from it.
- Add a logic to our PSI that will allow it to be inspected in 1:1 format as in Elixir
- Take the entire Spitfire test suite and port it to Kotlin Parser Tests, but use our Elixir-like inspections in place of PSI dumps
- Then port Spitfire code itself to Kotlin and to use IntelliJ AST builders and our lexer as I/O