Back to the question on what we should do with libsyntax2.
To start, I’d like to make a couple of general observations.
First, “merging libsyntax2 into rustc” is not a goal, it’s an optimization of resources. By just switching the parser, we won’t get neither a better IDE, nor a better compiler.
Second, I think “amortized complexity analysis” also works here. Specifically, I don’t think that the amount of work required to integrate libsyntax2 into compiler at time T_1 will be larger then the work at time T_2 >= T_1. That means that the moment when it starts to be painful to maintain two compilers is the moment where it makes sense to initiate the merge. We don’t win much by merging earlier.
With this in mind, I think the plan proposed in 2019 Strategy for Rustc and the RLS makes sense, including the “for merging with rustc, let’s just see how it goes” bit.
Specifically, I’d like to at least implement macro expansion and module tree resolution in an alternative code analyzer before merging with rustc. I feel these are the core ingredients to make on-the-fly analysis work, and they are really challenging: module resolution is a fixed-point computation, intertwined with macro expansion which could create new modules, and it is also the bit that merges the real, ugly and quirky, file system world with idealized compiler vision.
Now, I think the most contentious bit of that plan is that it effectively proposes to start an alternative implementation of language server, instead of working off the current RLS code base, and I’d like to dig into this concern more.
First of all, to clear non-technical issues, you might think that @matklad just wants to be the “author” of rust language server and to prove that the RLS is somehow wrong. I would lie if I say that there isn’t a tiny little bit of that as well, but keep in mind that by switching onto the next code analyzer, I am abandoning my work on IntelliJ Rust as well.
But I hope this is irrelevant, because technical points bear much more weight:
- It is important to have
cargo +stable testbuild process for Code Analyzer, and RLS is incompatible with that. - Linking to Cargo and running compiler after the user haven’t typed anything for 1500 milliseconds is just a wrong approach to IDEs (see 2019 Strategy for Rustc and the RLS and Let proc macros pass information to the compiler for in-depth discussion)
- Having strong guarantees about how the world looks like and transnational/snapshots semantics is important, and RLS does not have that.
It’s also important that the primary role of that alternative language server is to be the test-bed for Code Analyzer. Shipping IDE experience to users, at least mid-term, is supposed to be done by integrating with Racer and existing RLS.