Rust 编译器错误 E0130 详解：为什么外部函数声明中禁止使用模式（Pattern）

本文围绕 Rust 编译器（rustc）的错误码 E0130 展开，主题是：在 extern 外部函数声明（foreign function declaration）的参数位置上使用模式（如元组模式 (a, b)）会导致编译失败。读完本篇后，你将理解 E0130 的触发条件与两条官方修复路径，并能结合 rustc_ast_passes 的 AST 验证源码，弄清编译器究竟在哪一步、按什么规则判定“这个参数是非法模式”。

一、E0130 是什么：错误信息与最小复现

E0130 对应的诊断消息为：

patterns aren't allowed in foreign function declarations

该错误码的官方文档位于 E0130.md，文档给出的出错示例是：在一个 extern "C" 块中，把参数的“名字”位置写成了元组模式 (a, b)，类型仍为 (u32, u32)：

// compile_fail, E0130
extern "C" {
    fn foo((a, b): (u32, u32)); // error: patterns aren't allowed in foreign
                                //        function declarations
}

注意这里的关键细节：类型本身没有问题（(u32, u32) 是一个合法的类型），有问题的只是参数名位置写成了解构模式 (a, b)。在函数体中（或闭包参数处）这样写是常见的元组解构，但在 extern 声明里，编译器会直接在 AST 验证阶段拒绝它，报出 E0130。

该错误的回归验证用例位于 tests/ui/error-codes/E0130.rs，配套的预期诊断输出保存在 tests/ui/error-codes/E0130.stderr，可作为诊断文案与位置的基准。

二、两条官方修复路径

原文档给出了两种等价且都合法的修复方式，核心思想一致：把模式参数替换回普通的标识符参数。

路径 1：改用普通标识符接收整个类型

如果外部函数在 ABI 层面实际传递的是一个聚合体，最贴近真实 ABI 的写法是直接声明该类型：

struct SomeStruct {
    a: u32,
    b: u32,
}

extern "C" {
    fn foo(s: SomeStruct); // ok!
}

路径 2：只写参数名，保留元组类型

如果确实需要保持 (u32, u32) 的签名，只需要让参数名退化为一个普通标识符即可：

extern "C" {
    fn foo(a: (u32, u32)); // ok!
}

两种写法的差异在于调用侧的绑定形态：前者把整个值绑定为 s，后者把整个值绑定为 a（其类型为元组），而元组的分解应在调用方按需用 if let (x, y) = foo(...) 完成，而不是写进 extern 声明。

三、原理：为什么 extern 声明不允许模式

extern 块中声明的函数没有函数体，且其实现位于 Rust 编译器管辖之外（C 库、系统 API 等）。在这种声明里：

• 参数名仅用于文档说明与调用侧的类型检查，不生成任何 ABI 层面的绑定代码；
• 模式（pattern）的语义是“在函数体入口处对实参进行解构绑定”，没有函数体，解构就没有可执行的位置；
• 外部符号的签名不受 rustc 验证，编译器不允许在声明处引入任何“会误导实现细节”的绑定形态。

因此规则是：extern 函数参数只允许“无害的名字占位”——普通标识符或通配符 _，其余一律拒绝。这一语义约束在源码中通过精确的匹配规则体现（见下一节）。

四、源码级实现：E0130 在何处被检测

4.1 检测发生在 AST 验证阶段

E0130 属于编译流程前段的硬性错误（error），由 rustc_ast_passes crate 的 AST 验证逻辑发出，而不是 lint。诊断结构体定义在 rustc_ast_passes/src/diagnostics.rs：

#[derive(Diagnostic)]
#[diag("patterns aren't allowed in foreign function declarations", code = E0130)]
// FIXME: deduplicate with rustc_lint (`BuiltinLintDiag::PatternsInFnsWithoutBody`)
pub(crate) struct PatternInForeign {
    #[primary_span]
    #[label("pattern not allowed in foreign function")]
    pub span: Span,
}

从源码结构看，这里附带一条 FIXME 注释，说明维护者有意将 E0130/E0642 与 rustc_lint 中的 BuiltinLintDiag::PatternsInFnsWithoutBody 合并去重——这也解释了为什么“无函数体函数禁止模式”这一约束在 rustc 中有错误码与 lint 两套并行实现（见第五节）。

4.2 判定规则：哪些参数模式被放行

核心检查逻辑位于 rustc_ast_passes/src/ast_validation.rs 的 check_decl_no_pat 方法。它遍历无函数体函数的每个参数，按 AST 的 PatKind 分类处理：

fn check_decl_no_pat(decl: &FnDecl, mut report_err: impl FnMut(Span, Option<Ident>, bool)) {
    for Param { pat, .. } in &decl.inputs {
        match pat.kind {
            // 允许：省略名、普通标识符、通配符
            PatKind::Missing | PatKind::Ident(BindingMode::NONE, _, None) | PatKind::Wild => {}
            // mut 绑定标识符：交给 lint 处理（关联函数场景）
            PatKind::Ident(BindingMode::MUT, ident, None) => {
                report_err(pat.span, Some(ident), true)
            }
            // 其余一切模式：报错
            _ => report_err(pat.span, None, false),
        }
    }
}

这张表可以完整刻画“允许/禁止”边界：

参数模式形态	AST 形态	处理结果
普通标识符 a	PatKind::Ident(BindingMode::NONE, ..)	放行
通配符 _	PatKind::Wild	放行
缺省名 Missing	PatKind::Missing	放行
mut a	PatKind::Ident(BindingMode::MUT, ..)	转交 patterns_in_fns_without_body lint（关联函数场景）
元组模式 (a, b)、结构体模式、字面量模式等	其他 PatKind	报错：extern 块 → E0130；其他无体函数 → E0642

4.3 分派逻辑：E0130 与 E0642 的岔路

check_decl_no_pat 的回调在 ast_validation.rs 中被调用，针对“声明了但没有函数体（body: None）”的函数进行分支：

// Functions without bodies cannot have patterns.
if let FnKind::Fn(ctxt, _, Fn { body: None, sig, .. }) = fk {
    Self::check_decl_no_pat(&sig.decl, |span, ident, mut_ident| {
        if mut_ident && matches!(ctxt, FnCtxt::Assoc(_)) {
            // mut 标识符 + 关联函数（trait 等）→ 缓冲为 lint
            self.lint_buffer.dyn_buffer_lint(
                PATTERNS_IN_FNS_WITHOUT_BODY, id, span,
                move |dcx, level| { /* PatternsInFnsWithoutBody::Foreign/Bodiless */ },
            )
        } else {
            match ctxt {
                FnCtxt::Foreign => {
                    self.dcx().emit_err(diagnostics::PatternInForeign { span })   // E0130
                }
                _ => self.dcx().emit_err(diagnostics::PatternInBodiless { span }), // E0642
            }
        }
    });
}

从中可以读出三条结论：

1. 检查对象是 body: None 的函数：这正是 extern 块声明与 trait 中无默认实现的关联函数共有的形态，所以两条错误码共享同一个检测器；
2. 分派依据是函数上下文（FnCtxt）：上下文为 Foreign（extern 块内）时发出 PatternInForeign（即 E0130）；其他无体函数上下文发出 PatternInBodiless，对应的错误码是 E0642（“patterns aren't allowed in functions without bodies”），两者定义在 diagnostics.rs 中相邻位置；
3. mut 标识符走 lint 通道：当函数是关联函数（trait 内）且参数写成 mut ident 时，不直接报错，而是缓冲为内建 lint patterns_in_fns_without_body。该 lint 在 rustc_lint_defs/src/builtin.rs 中以 PATTERNS_IN_FNS_WITHOUT_BODY 注册，其文档注释说明它专门用于检测“无体函数中的 mut 标识符”这一较轻微的情形。

五、实践建议

• 编写 FFI 声明时，参数位置只使用 ident 或 _；需要解构时把解构逻辑留在调用侧。
• 若错误出现在 trait 关联函数而非 extern 块，报错会变为 E0642，修复方式相同（改为普通标识符）；若只是 mut 命名参数出现在 trait 中，则看到的是 patterns_in_fns_without_body lint，去掉 mut 即可消除。
• 排查此类错误时可直接定位到 rustc_ast_passes/src/ast_validation.rs 的 check_decl_no_pat，它是“无体函数参数模式”规则的唯一权威来源。
• 官方错误码文档（如 E0130.md）配套 compile_fail 测试与 tests/ui/error-codes/ 下的回归用例，诊断文案若发生变化，这些用例会同步校验，可作为编译器行为的事实依据。