3 ms·
https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html was the announcement of the replacement, a
by steveklabnik 4y ago
https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html was the announcement of the replacement, and talks about it a little bit:
> RLS was introduced by RFC 1317 and development was very active from 2016 through 2019. However, the architecture of RLS has several limitations that can make it difficult to provide low-latency and high-quality responses needed for an interactive environment.
> rust-analyzer uses a fundamentally different approach that does not rely on using rustc. In RFC 2912 rust-analyzer was adopted as the official replacement for RLS.
These RFCs provide some more color.
The long and short of it is, the RLS relied on a process where rustc would sort of pre-process your codebase, and spit out a "save analysis" file. RLS would read this file, and do its thing. rust-analyzer, on the other hand, doesn't use rustc at all(*), and instead analyzes your code on-demand, in an incremental style. The latter has many advantages in an IDE context.
The * is there because part of the original idea is that rustc would end up producing some libraries that rust-analyzer would also use, allowing them to share code. Given that rustc has also been moving towards an incremental, on-demand architecture, this would be easier. I am out of the loop these days, but from the relative outside, this effort seemed to stall out. I don't really know why. Maybe it has been happening and just isn't really visible.
Regardless of those details, rust-analyzer is very good. It's a shame the transition took so long, in retrospect!
- rektide 4y agoVery cool. Thanks for the links & write up!