锈病分析器是一个实验性的IDE/面向延迟的锈病编译器。这是锈病生态系统中一个新兴的努力，旨在提供关于锈病的经验。

编译器性能一直是Rust工具开发的主要关注点，编译时间在各个版本中都在稳步提高。然而，正如Igor Matuszewski在他的锈带锈的会议演讲中所解释的，锈IDE的支持是一个积极的工作领域:

尽管在过去的三年中，情况发生了很大的变化，包括新工具的大量出现和工具间集成的改进，但是感觉IDE生锈的故事还没有结束。

这项工作是在RLS 2.0工作组的指导下进行的，其中包括其主要组件锈的分析仪。InfoQ借此机会采访了toRust Analyzer的主要贡献者Aleksey Kladov和Rust核心团队成员Steve Klabnik，以了解更多关于它的信息。

InfoQ: Rust最近引起了很多人的兴趣，并且该语言一直在以非常快的速度演进和发展它的生态系统/工具。isRust目前的成熟度状况如何，在未来几年我们可以期待什么?

Steve Klabnik:“成熟”可以有很多含义。对我来说，衡量的标准是公司在真正的产品中使用锈。今天，它看起来像:

和更多。五分之三的仙灵还不错。

通常情况下，Rust正在减慢速度，并且获得更少的新特性，并对现有的东西进行更多的改进。例如，现在async/await已经发布了，更多的工作放在了诸如诊断之类的事情上。在接下来的几年里，Rust将会获得更多的重要特性，但是与异步/等待对于网络应用程序的好处类似，这些特性在特定的领域非常有价值，但是对于所有的Rust程序员来说可能并不重要。例如，“const泛型”允许您编写整数上的泛型代码，而不仅仅是类型，这对于数字类库来说是非常好的。但总的来说，这些功能的添加速度比以前的主要功能要慢。

InfoQ:您能简要解释一下当前的Rust编译器在IDE集成方面的局限性吗?锈病分析器项目的目标是什么?

Aleksey Kladov:这里的限制并不是专门针对Rust语言的，而是针对命令行与IDE编译器的通用限制。

主要的问题是，命令行(或批处理)编译器主要针对吞吐量进行优化(每秒编译N千行代码)，而IDE编译器针对延迟进行优化(在用户键入新代码片段后，在M毫秒内显示正确的补全变量)。与吞吐量vs延迟一样，这两个目标需要非常不同的优化(甚至高级架构)。一般来说，很难对只考虑大吞吐量开发的编译器进行低延迟要求的改进。

另一件事是处理无效代码的不同。传统的编译器前端通常是按阶段进行组织的，每个阶段接受一个非结构化的输入，检查输入的有效性，如果输入确实有效，则在上面添加更多的结构。具体来说，早期阶段(如解析)的错误通常意味着后期阶段(如类型检查)根本不运行这段代码。换句话说，“正确的代码”是一种很好的情况，其他的一切都可以看作是错误条件。相反，在IDE中代码总是被破坏，因为用户不断地修改它。一旦代码有效，IDE的工作就结束，批编译器的工作就开始。因此，面向IDE的编译器应该能够容纳不完整和不完整的代码，并为这些代码提供IDE特性，比如补全。

Rust -analyzer项目的首要目标是提供一个在延迟和吞吐量方面都有优异成绩的单一的Rust编译器。实现这一目标的道路是漫长的，因此目前我们正处于实际上有两个前端的阶段:

这个前端目前共享一小段代码，当前的战术目标是在它们之间共享更多容易共享的代码。

InfoQ:这个项目会取代Rust LSP实现吗?

克拉多夫:目前还没有;rust-analyzer只是一个实验，我们还没有准备好推荐它作为正式的LSP实现。然而，目前的初步计划是，在不久的将来，锈病分析仪将取代RLS。

InfoQ:你能分享一些关于编译器重构将会朝哪个方向发展的细节吗?

克拉多夫:主要思想是让编译器变得更懒。IDE可以用来实现低延迟的一个最重要的技巧是避免尽可能多的工作。例如，要提供代码补全，通常需要分析屏幕上的代码及其直接依赖项;您并不关心项目中其他500万行代码中编写了什么。这个想法很简单，但是让编译器不去查看额外的代码实际上是相当棘手的，这就是大部分工作要做的地方。我们计划做的一些更具体的事情是:

所有这些东西都已经在rust-analyzer中实现了，但是是以一种概念验证的方式实现的。棘手的一点是，在不破坏用户代码的情况下，将它们全部移到生产编译器中。