RustRover 中最常见的 Rust 编译器错误（下）| 技术解析

在上期博客中，我们根据 RustRover 的使用数据深入分析了 10 大最常见 Rust 编译器错误中的后 5 个。在本部分中，我们将探讨最常发生的前 5 大错误，并对 Rust 编程语言中最容易使开发者与编译器产生“冲突”的方面进行一些更总体的观察。

常见错误 #5：E0433（使用了未声明的 crate、模块或类型）

这个错误类似于上一部分中谈到的 E0432（import 未解析）。唯一的区别是，具有问题组件的路径直接在名称中使用，不带 use 子句。17.5% 的 RustRover 用户遇到过这个错误。例如，在下面的代码中，编译器无法理解我们真正的意图（crate 还是模块）并报错：

这个示例展示了 Rust 编译器备受好评的错误消息传递。即使不阅读消息，修正也显而易见：验证名称，根据需要将所需的依赖项添加到Cargo.toml，或者引入适当的 import。

RustRover 也可以发挥作用， 让我们选择导入的名称。

编写代码时使用代码补全就可以完全避免这种错误。

常见错误 #4：E0425（使用了未解析的名称）

接下来是另一个“未解析”的错误。20.5% 的 RustRover 用户遇到过这种情况：使用了未解析的名称，它在语法上不是 crate 或模块名称。发生这种错误时会弹出：

当然，实际发生时，情况可能不会像上图中那样明朗。

可惜，即使是了不起的 Rust 编译器也难以应对这种错误。可以采取的方式是：修订名称、提供定义或引入适当的 import。

常见错误 #3：E0599（方法用于未实现该方法的类型）

剧透预警：从现在起都将是类型检查错误！没错，前三名的错误都与不正确的类型使用相关。这里的错误是，27.5% 的 RustRover 用户曾试图在未实现方法的类型的值调用上该方法。来看下面的例子：

fnmain(){
letnumbers:Vec=vec![4,11,15,12];
letsum:usize=numbers.sum();
println!("Answer={sum}");
}

看起来没问题，只是没有作用于 Vec 的 sum 方法。具体错误消息如下：

error[E0599]:`Vec`isnotaniterator

这里的修正是首先调用 iter 方法，然后在生成的迭代器上使用 sum。

另外，RustRover 有一项功能可以防止这种错误， 即链式补全。要查看实际益处，请查看以下示例：

当补全建议被采纳时，iter 和 sum 方法都会添加到调用链中，立即修正代码。

通常，代码补全可以帮助您避免 E0599 消息。如果您没有看到所需方法调用的建议，那么真正的问题可能是被调用方类型不正确。

这个错误还有一个方面值得一提：在许多上下文中，您可以控制自己的类型声明。一种选项是首先调用一个方法，然后按 Alt-Enter (⌥Option–Return) 并执行建议的操作让 RustRover 搭建其实现：

操作的结果是，RustRover 生成方法实现模板，同时考虑到有关类型的所有上下文信息：

implInfo{
pub(crate)fnsummary(&self)->String{
todo!()
}
}

运行这段代码会导致运行时错误，但至少编译器不再报错。

常见错误 #2：E0308（预期类型与接收的类型不匹配）

设想一下：在需要类型 B 的值的上下文中使用了类型 A 的表达式。这里的“上下文”可以指调用点处的函数形参、变量声明、控制流语句/表达式等。如果您遇到过这个问题，那么您也是 30% 的 RustRover 用户中的一员。

理论上，对于这种情况我们有两种选择：调整值或调整上下文。调整值可能涉及转换类型、引用/解引用、在值上调用转换方法或将其替换为其他内容。调整上下文并不总是可行，有时我们可以更改预期类型来匹配接收的类型。

RustRover 通过提供快速修复选项支持两种操作模式，例如：

注意列表中的第二个建议：在这种情况下，RustRover 提出了适合编译器的相当复杂的值转换。遵循第一个建议将修正上下文，即函数定义。

常见错误 #1：E0277（尝试使用一个类型，但该类型未在需要特征的位置实现特征）

我们终于到榜首了！RustRover 中最常见的 Rust 编译器错误是 E0277， 32% 的 RustRover 用户经历过这种以类型和特征为主题的开发者噩梦。像往常一样，官方说明很好地提供了示例并解释了可能的修正。我们来关注 RustRover 的行为。

对于这种错误，我最喜欢的 RustRover 功能如下所示：

编译器报错：

error[E0277]:`Info`doesn'timplement`std::fmt::Display`

当然，实现 Display 特征是其中一种选择，RustRover 也很乐意搭建实现。但在这种情况下，我更倾向于采用第一个建议，其中涉及两个同时进行的步骤：

• 派生 Debug 特征的实现。

• 更改格式字符串以调用 Debug 特征的格式化功能。

然而，在许多其他情况下，RustRover 无法自行发现和高亮显示此错误。如前一部分所述，它的类型检查功能还没有那么强大，但我们正在改进。作为最常见的错误消息，E0277 当然在我们的关注范围之内。

Rust 错误的总体观察

我们来看概况。上周，我们向 X（以前称为 Twitter）社区询问 Rust 编程语言的什么方面是代码错误的主要来源。以下是我们得到的回复：

为了将社区回复与我们从数据中观察到的结果进行比较，我们研究了 25 个最常见的 Rust 编译器错误，并将其大致分为五类：

• 类型和特征

• 所有权和生命周期

• 宏

• 未解析的名称或不存在的元素

• 其他

结果如下（按错误代码数字从小到大的顺序排列）：

很遗憾，我们掌握的数据并没有太多关于宏的信息。我们既无法可靠地检测宏展开问题，也无法识别源自成功展开的宏的其他错误。也许这表明我们应该对收集的数据进行更精细的分类。

不考虑宏，前 25 大常见错误中似乎没有明显的赢家，这说明我们平等地喜爱 Rust 的每一面：

• 类型和特征 – 7 个错误

• 所有权和生命周期 – 8 个错误

• 未解析的名称或不存在的元素 – 7 个错误

• 其他 – 3 个错误

概要

在本系列的这一部分中，我们研究了 RustRover 中的五大最常见 Rust 编译器错误。其中三种错误与类型和特征有关，表明这一错误类别对于正确编写 Rust 代码颇为关键。我们观察了 25 个最常见错误的总体数据，意识到 Rust 的其他方面也会导致我们经常遇到的错误。

本博文英文原作者：Vitaly Bragilevsky

RustRover 相关阅读

关于 RustRover

RustRover 是 JetBrains 在 2023 年推出的面向 Rust 开发者的全新 IDE，正处于公开预览阶段，供大众免费使用体验。

进一步了解 Qodana

⏬ 戳「阅读原文」了解更多信息