Rust 编译错误 E0533 详解：为什么模式匹配里不能用方法名，以及如何修复（附 rustc 源码分析）

E0533 是 rustc 在模式匹配阶段抛出的错误：当你在 match / if let 等模式中写入了一个既不是 unit struct、也不是 unit variant、更不是常量的项目（例如关联函数、方法、带字段的枚举变体）时，编译器就会报出 expected unit struct, unit variant or constant。本文基于 Rust 官方错误码文档 E0533.md，完整还原报错场景与官方推荐的修复方式，并深入 rustc_hir_typeck 的类型检查源码，说明 rustc 究竟在哪里、依据什么判定逻辑发出这条诊断，帮助你在遇到该错误时快速定位原因并写出可编译的模式匹配代码。

一、E0533 的触发条件与错误信息

Rust 的模式语法是受限的：一个"裸路径模式"（bare path pattern）只能绑定一个零大小、可直接求值的对象，也就是 unit struct、unit variant、常量（const）或关联常量（AssocConst）。一旦路径解析到了函数、方法、结构体构造器（CtorKind::Fn）或带字段的枚举变体，rustc 就会报 E0533，诊断消息形如：

expected unit struct, unit variant or constant, found <res_descr> `<path>`

其中 <res_descr> 由解析结果决定：DefKind::Variant 显示为 struct variant，关联函数则显示其自身的描述。

官方文档中的错误示例

以下即 E0533.md 中给出的 compile_fail 示例（注意 Tortoise::turtle 是方法名，在模式中非法）：

struct Tortoise;

impl Tortoise {
    fn turtle(&self) -> u32 { 0 }
}

match 0u32 {
    Tortoise::turtle => {} // Error!
    _ => {}
}
if let Tortoise::turtle = 0u32 {} // Same error!

两点值得注意：

1. match 与 if let 都会触发：两者在 HIR 层面都走同一套模式检查路径，所以示例中两种写法报的是同一个错误；
2. 即使被匹配的值类型（u32）与"函数"完全不相关，错误也会先于类型错误被发出——因为模式检查在解析路径时就已拒绝该用法。

二、修复方式

方式一（官方推荐）：先绑定值，再用守卫比较

官方文档给出的修复思路是：把被匹配的值先绑定到变量，然后在 guard（if 条件）里调用方法并比较，因为 guard 是普通表达式上下文，允许方法调用：

struct Tortoise;

impl Tortoise {
    fn turtle(&self) -> u32 { 0 }
}

match 0u32 {
    x if x == Tortoise.turtle() => {} // Bound into `x` then we compare it!
    _ => {}
}

if let x if cond = expr 的守卫部分本质上是布尔表达式，因此 Tortoise.turtle() 这样的方法调用在 guard 中完全合法。

方式二：改用常量或关联常量

如果目的是"匹配某个固定的值"，最 idiomatic 的做法是把该值定义为 const 或 trait 内的关联常量——这两者都是裸路径模式的合法目标（对应源码中 DefKind::Const 与 DefKind::AssocConst 分支，检查直接放行）：

const TURTLE: u32 = 0;

match 0u32 {
    TURTLE => {}    // 常量模式，合法
    _ => {}
}

方式三：如果是带字段的变体，改用构造器模式

当 E0533 由"在模式里写了带字段的枚举变体名"触发时，正确写法是补全模式语法。rustc 的诊断逻辑甚至会直接给出这一建议（见下文源码分析）：unit 变体建议补 {}，带字段变体建议补 { field: /* value */ }：

enum Color {
    Red,
    Rgb { r: u8, g: u8, b: u8 },
}

let c = Color::Rgb { r: 1, g: 2, b: 3 };
match c {
    Color::Red {} => {}              // unit 变体可省略 {}，但写上合法
    Color::Rgb { r, g, b } => {}     // 结构体模式，合法
}

三、源码剖析：rustc 在哪里发出 E0533

E0533 的诊断集中在 rustc_hir_typeck 中，共有三处调用点，分别对应模式上下文、Self 构造器上下文和表达式上下文。

1. 模式路径解析：resolve_pat_path（主要来源）

模式检查的核心入口是 resolve_pat_path（pat.rs）。它先通过 resolve_ty_and_res_fully_qualified_call 拿到路径的解析结果 Res，然后按定义种类分支：

// compiler/rustc_hir_typeck/src/pat.rs（节选）
Res::Def(DefKind::AssocFn | DefKind::Ctor(_, CtorKind::Fn) | DefKind::Variant, _) => {
    let expected = "unit struct, unit variant or constant";
    let e = self.report_unexpected_variant_res(
        res, None, &[], qpath, span, E0533, expected,
    );
    return Err(e);
}

• DefKind::AssocFn：关联函数/方法——正是文档示例中 Tortoise::turtle 命中这里的原因；
• DefKind::Ctor(_, CtorKind::Fn)：元组结构体/元组变体的构造器函数（如 Point(x, y) 这类"函数式构造器"）在裸路径模式下同样非法；
• DefKind::Variant：带字段的枚举变体在模式中缺了构造器语法时命中。

放行分支则是文档所述三类合法目标：

Res::Def(
    DefKind::Ctor(_, CtorKind::Const)  // unit 构造器
    | DefKind::Const { .. }            // const
    | DefKind::AssocConst { .. }       // 关联常量
    | DefKind::ConstParam,             // 常量类型参数
    ..,
) => {} // OK

2. Self 构造器的特判

当模式路径解析到 Self 时（Res::SelfCtor），pat.rs 中紧随其后的分支要求该类型必须恰好是 unit struct（adt_def.is_struct() 且非枚举变体上的 CtorKind::Const 构造器）：

// compiler/rustc_hir_typeck/src/pat.rs（节选）
// Ok, we allow unit struct ctors in patterns only.
} else {
    let e = self.report_unexpected_variant_res(
        res, None, &[], qpath, span, E0533, "unit struct",
    );
    return Err(e);
}

源码中的注释 we allow unit struct ctors in patterns only 直接印证了文档标题的表述：能进模式的只有 unit struct。

3. 表达式上下文的 E0533

E0533 并非只出现在模式中。在 expr.rs 的值路径处理 里，如果把一个带字段的枚举变体当作普通值路径使用（缺了 () 或 {} 构造语法），同样报 E0533，只是期望文案变为 "value"：

// compiler/rustc_hir_typeck/src/expr.rs（节选）
Res::Def(DefKind::Variant, _) => {
    let e = self.report_unexpected_variant_res(
        res, Some(expr), &[], qpath, expr.span, E0533, "value",
    );
    Ty::new_error(tcx, e)
}

4. 诊断的统一构造：report_unexpected_variant_res

三处调用点最终汇聚到 report_unexpected_variant_res（lib.rs）。该函数负责拼装诊断并计算智能建议：

• 生成 expected {expected}, found {res_descr} \{path_str}`主消息，并用with_code(E0533)` 绑定错误码；
• 表达式 + Variant 场景：若变体无字段，建议追加 {}；有字段则生成 { field: /* value */, ... } 的多段建议（multipart_suggestion），提示 "you might have meant to create a new value of the struct"；
• 模式 + Variant 场景（expr.is_none()）：给出 "use the struct variant pattern syntax" / "add the names to match a struct variant's fields" 的提示，并逐字段生成模式写法建议。

也就是说，前文"修复方式三"中 rustc 自动给出的构造器补全建议，其实现就在这个函数里。

5. 顺带一提：关联错误 E0164

从 lib.rs 的诊断分支 可以看到，普通自由函数（DefKind::Fn）出现在模式中时走的是 E0164 分支（提示 "fn calls are not allowed in patterns"）。可以推断：E0533 与 E0164 是同一类"模式里用了非模式对象"错误的两个分工——函数归 E0164，关联函数/构造器/带字段变体归 E0533。排查时若看到 E0164，可参照本文思路处理。

四、小结

• 一句话判据：裸路径模式只接受 unit struct、unit variant、常量与关联常量；方法名、函数式构造器、带字段变体一律 E0533。
• 三条修复路径：
  1. 方法/函数比较 → 先绑定再用 guard（x if x == foo.bar()），这是 E0533.md 的官方修法；
  2. 固定值 → 定义为 const / 关联常量后直接作模式；
  3. 带字段变体 → 补全 { ... } 或 ( ... ) 构造器模式，rustc 诊断通常已给出带字段名的现成建议。
• 源码定位：模式上下文报错点在 pat.rs resolve_pat_path，表达式上下文在 expr.rs，诊断与建议统一由 lib.rs report_unexpected_variant_res 生成。理解这条调用链后，再遇到 expected unit struct, unit variant or constant 类报错，就能从诊断文案直接反推出解析结果属于哪一类定义、应当如何改写。