Rust 编译器错误 E0532：模式分支类型不匹配（Pattern arm kind mismatch）的原理与修复

E0532 是 Rust 编译器在名称解析（resolve）阶段抛出的错误，提示你在 match / let 等模式匹配中，某个分支（pattern arm）所使用的构造体类型与实际要匹配的值不一致——典型场景是把一个**元组变体（tuple variant）或结构体变体（struct variant）当作单元变体（unit variant）**来写。读完本文，你能准确定位 E0532 的触发条件，理解它在 rustc_resolve 底层是如何被判定与报错的，并能一次性修复这类模式类型不匹配的问题。

E0532 的核心含义

E0532 的官方标题是：

Pattern arm did not match expected kind. （模式分支不匹配预期的种类。）

它描述的是这样一种情况：一个 enum 的某个变体携带了数据（元组或结构体字段），你在模式里却只写了变体名而没有给出与之对应的字段绑定；或者反过来，匹配结构与实际形状不符。官方文档中的错误示例如下（摘自 E0532.md）：

enum State {
    Succeeded,
    Failed(String),
}

fn print_on_failure(state: &State) {
    match *state {
        // error: expected unit struct, unit variant or constant, found tuple
        //        variant `State::Failed`
        State::Failed => println!("Failed"),
        _ => ()
    }
}

这里 State::Failed 是携带 String 的元组变体，但模式 State::Failed 没有括号和绑定，编译器把它当成一个"单元"构造体来解析，于是报出：

expected unit struct, unit variant or constant, found tuple variant `State::Failed`

修复方式

官方给出的修复原则非常直接：确保模式分支的种类（kind）与所匹配的表达式的形状一致。对于携带数据的变体，必须用括号把字段"拆"出来（或按结构体字段名绑定）。

修复后的示例（摘自 E0532.md）：

enum State {
    Succeeded,
    Failed(String),
}

fn print_on_failure(state: &State) {
    match *state {
        State::Failed(ref msg) => println!("Failed with {}", msg),
        _ => ()
    }
}

关键点：State::Failed(ref msg) 通过 (ref msg) 把元组里的 String 以引用形式绑定到 msg，从而让模式的形状与 Failed(String) 完全对齐。若你只是想匹配而不关心数据，也可以用 State::Failed(_) 显式占位。

适用前提：E0532 属于 resolve（名称解析）阶段的错误，因此它对能否正确匹配到定义并不敏感，而敏感于匹配到的定义是否是预期的"种类"。这一点在下面的源码分析中会进一步印证。

源码级原理：E0532 在哪里被判定与发射

E0532 的产生完全发生在 rustc_resolve 的**晚期解析（late resolution）**中，而非类型检查（typeck）。下面沿着源码梳理判定与报错的完整链路。

1. 模式路径的"预期种类"（PathSource::Pat）

解析路径时会记录一个 PathSource，用来表示"当前这个路径出现在什么上下文"。对于裸的单元模式路径（如上面的 State::Failed），上下文是 PathSource::Pat；对于元组/结构体构造模式（如 State::Failed(...)），上下文是 PathSource::TupleStruct(..)。

在 late.rs 中，descr_expected() 为每种上下文给出"预期应该是什么"：

fn descr_expected(self) -> &'static str {
    match &self {
        // ...
        PathSource::Pat => "unit struct, unit variant or constant",
        PathSource::Struct(_) => "struct, variant or union type",
        PathSource::TraitItem(ValueNS, PathSource::TupleStruct(..))
        | PathSource::TupleStruct(..) => "tuple struct or tuple variant",
        // ...
    }
}

这解释了报错信息前半句 expected unit struct, unit variant or constant——它就是 PathSource::Pat 的 descr_expected() 返回值。

2. 一个解析结果"是否合法"的判定

解析出 Res（resolution，即路径指向的定义）后，需要判断它是否"可以被用作该上下文中的构造体"。相关逻辑在 late.rs：

PathSource::Pat => {
    res.expected_in_unit_struct_pat()
        || matches!(
            res,
            Res::Def(DefKind::Const { .. } | DefKind::AssocConst { .. }, _)
        )
}
PathSource::TupleStruct(..) => res.expected_in_tuple_struct_pat(),

这两个辅助方法定义在 rustc_hir/src/def.rs：

/// Returns whether such a resolved path can occur in a tuple struct/variant pattern
pub fn expected_in_tuple_struct_pat(&self) -> bool {
    matches!(self, Res::Def(DefKind::Ctor(_, CtorKind::Fn), _) | Res::SelfCtor(..))
}

/// Returns whether such a resolved path can occur in a unit struct/variant pattern
pub fn expected_in_unit_struct_pat(&self) -> bool {
    matches!(self, Res::Def(DefKind::Ctor(_, CtorKind::Const), _) | Res::SelfCtor(..))
}

从源码结构看，二者以 CtorKind 区分：

• CtorKind::Const（零参数的单元构造体）→ 可用作单元模式（PathSource::Pat）；
• CtorKind::Fn（带参数、像函数一样"调用"的构造体）→ 可用作元组/结构体构造模式（PathSource::TupleStruct(..)）。

当你在 PathSource::Pat 上下文里写 State::Failed，解析到的 Res 是一个 CtorKind::Fn 的构造体，expected_in_unit_struct_pat() 返回 false（且它不是常量），因此判定为"解析成功但种类不符"，从而触发 E0532 分支。

3. 错误码的选择：E0532 vs E0531

E0532 与 E0531 成对出现，均由 late.rs 中的 error_code 依据一个布尔量 has_unexpected_resolution 分流：

fn error_code(self, has_unexpected_resolution: bool) -> ErrCode {
    match (self, has_unexpected_resolution) {
        // ...
        (PathSource::Pat | PathSource::TupleStruct(..), true) => E0532,
        (PathSource::Pat | PathSource::TupleStruct(..), false) => E0531,
        // ...
    }
}

可以推断：当路径确实解析到了一个真实存在的定义、但种类与上下文不符（即"非预期的解析结果"）时走 true 分支报 E0532；而当路径没能解析为预期种类（例如拼写错误或缺失导入导致的未知元组/结构体）时走 false 分支报 E0531（其标题见 E0531.md：“An unknown tuple struct/variant has been used.”）。本文的 State::Failed 情形属于前者，故命中 E0532。

4. 报错文案如何拼成

E0532 的文案由 late/diagnostics.rs 的 make_base_error 组装，其中 expected 取自上文的 source.descr_expected()，res.descr() 给出实际解析到的定义类型（如 "tuple variant"）：

fn make_base_error(&mut self, path: &[Segment], span: Span, source: PathSource<'_, '_, '_>, res: Option<Res>, could_be_expr: bool) -> BaseError {
    let mut expected = source.descr_expected();
    let path_str = Segment::names_to_string(path);

    if let Some(res) = res {
        BaseError {
            msg: format!("expected {}, found {} `{}`", expected, res.descr(), path_str),
            // ...
        }
    }
    // ...
}

代入本例：expected = "unit struct, unit variant or constant"、res.descr() = "tuple variant"、path_str = "State::Failed"，最终得到与文档一致的 expected unit struct, unit variant or constant, found tuple variant State::Failed``。

值得注意的一个细节：在 AST lowering 阶段，rustc_ast_lowering/src/expr.rs 的 extract_unit_struct_path 也会提前调用 res.expected_in_unit_struct_pat()，用于在早期快速拒绝那些"根本不是单元结构体"的路径——这说明"单元模式合法性"这一判断在编译器不同阶段被反复复用，是贯穿 resolve/lowering 的一致性约束。

用测试用例验证

仓库中有一个与 E0532 完全对应的 UI 测试，覆盖了"元组变体/结构体变体被当作单元模式"的两种子情形（对应 issue #63983），见 unit-pattern-error-on-tuple-and-struct-variants-63983.rs：

// https://github.com/rust-lang/rust/issues/63983
enum MyEnum {
    HasTupleField(i32),
    HasStructField{ s: i32 },
}

fn foo(en: MyEnum) {
    match en {
        MyEnum::HasTupleField => "",
//~^ ERROR expected unit struct, unit variant or constant, found tuple variant `MyEnum::HasTupleField`
        MyEnum::HasStructField => "",
//~^ ERROR expected unit struct, unit variant or constant, found struct variant `MyEnum::HasStructField`
    };
}

其期望输出记录在 unit-pattern-error-on-tuple-and-struct-variants-63983.stderr。这份测试印证了两点：E0532 同时覆盖"元组变体当单元模式"与"结构体变体当单元模式"两类误用；报错文案与源码中 descr_expected() + res.descr() 的拼接规则严格一致。

作为对照，反向误用（把单元变体当作元组模式，即 E::A(..)）会落到 PathSource::TupleStruct(..) 分支并报 expected tuple struct or tuple variant, found unit variant（E0531），参见 unit-variant-pattern-matching-29383.rs。理解这一正一反两个测试，能帮助你快速判断当前错误码到底指向"模式比定义多写了括号"还是"少写了括号"。

小结与排查清单

• E0532 的本质：模式分支（pattern arm）的构造体种类与被匹配值形状不一致，最常见是把携带数据的元组/结构体变体当成单元变体来匹配。
• 快速修复：为变体补上与定义一致的字段绑定——元组变体用 Variant(field1, field2, ...)（或占位 _、ref 借用），结构体变体用 Variant { field: pat }。
• 源码定位：判定与发射集中在 rustc_resolve/src/late.rs（descr_expected、error_code），合法性判定在 rustc_hir/src/def.rs（expected_in_unit_struct_pat / expected_in_tuple_struct_pat），文案在 late/diagnostics.rs 的 make_base_error。
• 区分 E0531 / E0532：E0532 是"解析到了真实定义但种类不符"，E0531 是"未能解析为预期种类（未知/拼写/导入缺失）"；两者共享 PathSource::Pat | PathSource::TupleStruct(..) 的匹配分支，仅以 has_unexpected_resolution 布尔量区分。
• 验证依据：可运行或查阅 E0532.md 中的 compile_fail,E0532 示例，以及测试 unit-pattern-error-on-tuple-and-struct-variants-63983.rs 来复现并核对报错文案。