Rust analyzer是一个实验性的面向IDE/延迟的Rust编译器。这是rust生态系统中的一项新兴工作，旨在提供关于rust的经验。

编译器性能一直是Rust工具开发的主要关注点，所有版本的编译时间都在稳步增加。然而，正如Igor Matuszewski在他关于rust和rust的会议演讲中所解释的，rust IDE的支持是一个活跃的工作领域。

虽然在过去的三年里发生了很大的变化，包括大量新工具的出现和工具间集成性的提高，但是感觉IDE生锈的故事还没有结束。

这项工作是在RLS 2.0工作组的指导下进行的，包括其主要部件生锈的分析仪。InfoQ借此机会采访了《toRust Analyzer》的主要撰稿人Aleksey Kladov和Rust的核心团队成员Steve Klabnik，了解更多相关信息。

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

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

还有更多。五分之三的仙女还不错。

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

InfoQ:能否简单解释一下目前Rust编译器在IDE集成方面的局限性？铁锈分析仪项目的目标是什么？

Aleksey Kladov:在这里的限制不是特定于Rust语言的，而是对命令行和IDE编译器的一般限制。

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

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

Rust -analyzer项目的主要目标是提供一个在延迟和吞吐量方面都有出色性能的Rust编译器。实现这个目标的路还很长，所以目前我们处于实际拥有两个前端：的阶段。

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

InfoQ:会取代Rust LSP的实现吗？

Kladov :还没有上市；Rust-analyzer只是一个实验，我们还不准备推荐它作为正式的LSP实现。不过，目前的初步计划是，铁锈分析仪将在不久的将来取代RLS。

InfoQ:能分享一些关于编译器重构方向的细节吗？

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

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

版权说明： 本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。

标签：