Long-shot parser -> lib-ruby-parser transition for performance boost?

[pirj]

Last Ruby Weekly mentioned https://github.com/lib-ruby-parser/lib-ruby-parser, a replacement for Ripper/parser.
But it has no Ruby bindings yet. Ruby bindings are WIP though.

lib-ruby-parser mentions that

AST is strongly typed, and so if something is nullable it's explicitly defined and documented

I am not certain if it's good or would get us any benefits.

It slipped my mind why rubocop itself still depends on parser? Is it for rewriting?

[marcandre]

It slipped my mind why rubocop itself still depends on parser?

I'm not sure I follow the question. rubocop uses the AST generated via parser to inspect the Ruby code...

Is it for rewriting?

and yes, also for auto corrections, although the rewriter's code is completely generic and would be easy to port.

But unless that gem actually generates an AST, usable in Ruby, including locations, comments and tokens, that is 100% compatible with parser, I don't see how we could use it without breaking just about everything. In particular, every single node pattern, def on_send and al. depend on the "shape" of the AST.

So let's close this until this is the case.