Rust E0040 详解：为什么不能手动调用析构函数，以及 std::mem::drop 的正确用法

在 Rust 中，Drop trait 的 drop 方法只能由编译器在值离开作用域时自动调用，任何显式的 x.drop() 方法调用都会触发编译错误 E0040（"explicit use of destructor method"）。本文基于 Rust 官方错误代码文档 E0040.md，完整讲解该错误的触发场景、编译器给出的诊断输出与修复建议、标准库 std::mem::drop 的替代方案，并结合 rustc_hir_typeck 中的源码实现，剖析编译器是如何在方法调用类型检查阶段拦截非法析构调用的。读完本文，你将能够准确识别并修复 E0040，并理解编译器在底层强制执行"析构自动性"的完整调用链。

错误定义：手动调用析构函数在 Rust 中不被允许

E0040 的官方文档只有一句话作为核心定义：It is not allowed to manually call destructors in Rust.（Rust 中不允许手动调用析构函数）。这条规则是所有权系统的一部分：

• drop 是由编译器在值离开作用域（going out of scope）时自动调用的，用户代码不需要、也不应该显式触发；
• 如果确实需要提前释放某个值，标准做法是调用标准库函数 std::mem::drop，而不是调用 trait 方法 Drop::drop。

该文档通过 rustc --explain E0040 命令对开发者可见，源文件位于 compiler/rustc_error_codes/src/error_codes/E0040.md。

错误复现：直接调用 x.drop() 会发生什么

下面这段代码完整来自错误文档的示例，演示了触发 E0040 的典型写法：

struct Foo {
    x: i32,
}

impl Drop for Foo {
    fn drop(&mut self) {
        println!("kaboom");
    }
}

fn main() {
    let mut x = Foo { x: -7 };
    x.drop(); // error: explicit use of destructor method
}

编译后，编译器输出如下诊断信息（与 tests/ui/error-codes/E0040.stderr 中的期望输出一致）：

error[E0040]: explicit use of destructor method
  --> E0040.rs:16:7
   |
LL |     x.drop();
   |       ^^^^ explicit destructor calls not allowed
   |
help: consider using `drop` function
   |
LL -     x.drop();
LL +     drop(x);
   |

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0040`.

注意两个细节：

1. 错误标签（label）是 explicit destructor calls not allowed，与主消息 "explicit use of destructor method" 略有不同；
2. 编译器会主动给出一个机器可应用的修复建议：把 x.drop() 改写为 drop(x)，即改用 std::mem::drop 函数。

正确做法：用 std::mem::drop 手动释放值

文档给出的修复版本如下：

struct Foo {
    x: i32,
}
impl Drop for Foo {
    fn drop(&mut self) {
        println!("kaboom");
    }
}
fn main() {
    let mut x = Foo { x: -7 };
    drop(x); // ok!
}

drop(x) 调用的是标准库函数 std::mem::drop（在预lude导入场景下可直接写作 drop），它按值消费其参数，并在函数体中显式结束该值的生命周期，从而立即触发 Drop::drop。这个设计与直接调用方法有本质区别：

• x.drop() 只借用 &mut self，值 x 的所有权仍然保留，main 结束作用域时编译器还会再执行一次析构——显式调用会引入"双重析构"的隐患，因此编译器直接禁止这种写法；
• drop(x) 转移了所有权，保证析构恰好发生一次，语义清晰且安全。

从 tests/ui/error-codes/E0040.fixed 也可以看到，仓库测试用例的自动修复结果正是把 x.drop(); 替换为 drop(x);。

源码剖析：编译器如何拦截显式析构调用

E0040 并非由某个 lint 产生，而是类型检查（typeck）阶段的硬错误。检查发生在方法调用确认（method call confirmation）流程中，可以沿以下调用链追溯：

1. 方法确认阶段的入口检查

在 compiler/rustc_hir_typeck/src/method/confirm.rs 中，方法探测（probe）成功、接收者类型统一完成之后，有一行注释直白的检查：

// Make sure nobody calls `drop()` explicitly.
self.check_for_illegal_method_calls(pick);

check_for_illegal_method_calls 的实现位于同文件 confirm.rs#L699-L713。它先通过 pick.item.trait_container(self.tcx) 判断所调用的方法是否定义在某个 trait 上；如果是，则交给 callee::check_legal_trait_for_method_call 判断该 trait 是否允许被显式调用。

2. 核心判定：trait 是否为 Drop 语言项

真正的判定逻辑在 compiler/rustc_hir_typeck/src/callee.rs 的 check_legal_trait_for_method_call 中：

pub(crate) fn check_legal_trait_for_method_call(
    tcx: TyCtxt<'_>,
    span: Span,
    receiver: Option<Span>,
    expr_span: Span,
    trait_id: DefId,
    body_def_id: DefId,
) -> Result<(), ErrorGuaranteed> {
    if tcx.is_lang_item(trait_id, LangItem::Drop)
        // Allow calling `Drop::pin_drop` in `Drop::drop`
        && !tcx.is_lang_item(tcx.parent(body_def_id), LangItem::Drop)
    {
        let sugg = if let Some(receiver) = receiver.filter(|s| !s.is_empty()) {
            diagnostics::ExplicitDestructorCallSugg::Snippet { lo, hi }
        } else {
            diagnostics::ExplicitDestructorCallSugg::Empty(span)
        };
        return Err(tcx.dcx().emit_err(diagnostics::ExplicitDestructorCall { span, sugg }));
    }
    tcx.ensure_result().coherent_trait(trait_id)
}

从源码结构看有三个要点：

• 判定依据是语言项（lang item）：只要方法所属 trait 是 LangItem::Drop（通过 #[lang = "drop"] 标注的标准库 Drop trait），调用即非法——这与方法名是否叫 drop 无关，判定的是 trait 身份；
• 唯一的豁免场景：注释写明 "Allow calling Drop::pin_drop in Drop::drop"，即当当前函数体 body_def_id 的父项也是 Drop（tcx.parent(body_def_id) 是 LangItem::Drop）时放行。这允许在实现 Drop::drop 时通过 Pin 相关 API 访问字段，而不会误报 E0040；
• 建议的两种形态：如果能拿到接收者的 span（如 x.drop() 中的 x），则生成 Snippet 形态的改写建议（替换 x.drop 为 drop(x) 对应的片段）；否则退化为 Empty 形态，仅在调用位置提示考虑使用 drop 函数。

3. 诊断结构体与修复建议

诊断定义位于 compiler/rustc_hir_typeck/src/diagnostics.rs：

#[derive(Diagnostic)]
#[diag("explicit use of destructor method", code = E0040)]
pub(crate) struct ExplicitDestructorCall {
    #[primary_span]
    #[label("explicit destructor calls not allowed")]
    pub span: Span,
    #[subdiagnostic]
    pub sugg: ExplicitDestructorCallSugg,
}

#[derive(Subdiagnostic)]
pub(crate) enum ExplicitDestructorCallSugg {
    #[suggestion(
        "consider using `drop` function",
        code = "drop",
        applicability = "maybe-incorrect"
    )]
    Empty(#[primary_span] Span),
    // ...
}

其中 applicability = "maybe-incorrect" 表明该机器建议的适用性被保守标注为"可能不正确"——即 drop(x) 会转移所有权，如果后续代码还要使用 x，直接应用建议可能引入新的编译错误，需要开发者自行确认。

相关背景：为什么 Drop 在 trait bound 中也几乎没有用处

E0040 与编译器中的 drop_bounds / dyn_drop 两个 lint 存在语义关联。compiler/rustc_lint/src/traits.rs 中 drop_bounds lint 的文档注释明确写道：

Furthermore, the Drop trait only contains one method, Drop::drop, which may not be called explicitly in user code (E0040), so there is really no use case for using Drop in trait bounds...

也就是说，Drop trait 唯一的公开方法 drop 在用户代码中不可显式调用，因此把 T: Drop 当作"类型需要析构"的约束通常是错误意图（正确的工具是 std::mem::needs_drop::<T>()）。E0040 从方法调用侧、drop_bounds 从 bound 声明侧，共同封死了把 Drop 当普通 trait 使用的路径。

测试验证：如何在仓库中查看 E0040 的行为

仓库中的 UI 测试完整覆盖了该错误的行为契约，测试文件位于 tests/ui/error-codes/：

文件	作用
E0040.rs	触发 E0040 的测试源码，首行标注 //@ run-rustfix 表示修复后需通过编译
E0040.stderr	期望的完整诊断输出，锁定错误消息、标签与建议文案
E0040.fixed	rustfix 自动修复后的可编译版本

测试源码与错误文档中的示例一致：定义带 Drop 实现的 Foo，在 main 中对 x 执行 x.drop()，并用注释 //~^ ERROR E0040 标注期望报错的位置。这类 tests/ui/error-codes/ 下的用例同时也是 rustc --explain 文档与编译器行为之间的一致性保障。

总结

• 规则：Drop::drop 是编译器在值离开作用域时自动执行的，显式方法调用（x.drop()）是硬错误 E0040，不是 lint，无法用 #[allow] 关闭；
• 修复：需要手动、提前释放值时，使用 std::mem::drop：drop(x)，它按值消费参数，保证析构恰好一次；
• 实现位置：检查位于类型检查阶段的方法调用确认流程，入口在 method/confirm.rs 的 check_for_illegal_method_calls，核心判定在 callee.rs 的 check_legal_trait_for_method_call，依据 LangItem::Drop 语言项识别 Drop trait，仅豁免在 Drop::drop 实现内部对 Drop::pin_drop 的调用；
• 验证：修改相关行为后可运行 tests/ui/error-codes/E0040.rs 对应的 UI 测试，诊断文案由 E0040.stderr 精确锁定。