Rust 编译器错误码 E0007：match 子绑定双重移动问题与借用检查的演进

E0007 是 Rust 编译器历史错误码，用于报告 match 模式中的绑定要求同一个值被移动进多个位置，从而违反唯一所有权（unique ownership）规则。本文基于当前 Rust 编译器仓库中的官方错误码文档 E0007 展开，完整还原该错误的触发机制与错误示例，并结合当前编译器源码与测试用例，说明该错误码为何不再由编译器发出、其职责如何被 E0382 接管，以及 bindings_after_at 特性从 unstable 到 accepted 的演进轨迹，帮助读者准确理解 @ 绑定与所有权检查之间的关系。

E0007 的原始定义：一个值不能同时被移入两个位置

官方错误码文档（compiler/rustc_error_codes/src/error_codes/E0007.md）对 E0007 的定义非常明确：

This error indicates that the bindings in a match arm would require a value to be moved into more than one location, thus violating unique ownership.

即：当 match 分支中的多个绑定（@ 左侧的整体绑定与右侧子模式中的字段绑定）要求把同一个值移动进多个不同的位置时，就会触发该错误。文档给出的错误代码示例如下：

#![feature(bindings_after_at)]

let x = Some("s".to_string());

match x {
    op_string @ Some(s) => {}, // error: use of moved value
    None => {},
}

逐句拆解这段代码，可以看到双重移动的冲突点：

• let x = Some("s".to_string())：x 持有 Option<String>，其中内嵌的 String 是堆上数据，属于非 Copy 类型；
• 模式 op_string @ Some(s) 中包含两个绑定：
  • op_string：绑定整个 Option<String> 值，语义上要求把 x 的整体移动进 op_string；
  • s：绑定 Some 内部的 String，语义上要求把内层 String 从 x 中部分移出（partial move）进 s。

两条移动路径针对同一份堆数据（String 的堆缓冲区）提出了互斥的所有权转移——一份堆数据不可能同时完整地归属于 op_string，又被拆出去归属于 s。这正是“value to be moved into more than one location”的实质。

文档开头特别标注了一条重要说明：

Note: this error code is no longer emitted by the compiler.

也就是说，在当前版本的编译器中，E0007 已经不再被发出，上面的代码会转而报告 E0382（use of moved value）。错误文档末尾同时指向了相关历史错误码 E0303（compiler/rustc_error_codes/src/error_codes/E0303.md），两者共同构成了 @ 子绑定检查问题的完整脉络。

为什么 E0007 的报错职责被 E0382 接管

E0382 是当前 Rust 中“在值被移动后仍被使用”的标准报错，其文档（compiler/rustc_error_codes/src/error_codes/E0382.md）解释的核心原则与 E0007 完全同源：

Since MyStruct is a type that is not marked Copy, the data gets moved out of x when we set y. This is fundamental to Rust's ownership system: outside of workarounds like Rc, a value cannot be owned by more than one variable.

对于 op_string @ Some(s) 这种模式，@ 侧的整体绑定与右侧子绑定的冲突本质上就是“一个值被两个变量同时主张所有权”的特例。随着借用检查器（rustc_borrowck）对模式绑定的建模成熟，这类冲突统一归入了 move/borrow 分析的常规报错路径，E0007 作为独立错误码的历史使命完成，仓库中保留其文档页主要是为了错误码编号的连续性和历史可检索性。

由此得到的实践结论是：阅读旧资料或旧版编译器输出中遇到 E0007 时，应按 E0382 的思路排查——找到被双重主张所有权的那个绑定，消除其中一条移动路径。

E0303：同一问题的另一面——子绑定的内存安全检查

E0007 文档末尾“See also the error E0303”指向的错误码，处理的是同一语法位置的另一类风险。E0303 文档说明：子绑定（sub-bindings，例如 ref x @ Some(ref y)）现在在 #![feature(bindings_after_at)] 下被允许，且编译器会检查内存安全是否被破坏；但在某些情况下子绑定仍可能破坏内存安全，当时的建议是把模式改写为不含子绑定的形式，例如：

// 改写前（历史限制下的问题写法）
match Some("hi".to_string()) {
    ref op_string_ref @ Some(s) => {},
    None => {},
}

// 改写后：仅借用外层，再单独取引用
match Some("hi".to_string()) {
    Some(ref s) => {
        let op_string_ref = &Some(s);
        // ...
    },
    None => {},
}

文档指出，两种写法中 op_string_ref 的类型都是 &Option<&String>。这给出了 E0007 示例的一个通用解法方向：当整体绑定与内部绑定发生所有权冲突时，让整体绑定走引用（ref / ref mut）而非移动，只保留真正需要转移所有权的那一条路径。

bindings_after_at：从 unstable 到 accepted 的特性演进

E0007 示例代码首行的 #![feature(bindings_after_at)] 是理解时间线的关键。在当前仓库源码中，该特性的状态可以在特性注册表中直接确认：rustc_feature 的 accepted 列表中登记为：

(accepted, bindings_after_at, "1.56.0", Some(65490)),

这说明 bindings_after_at 已在 Rust 1.56.0 被接受（accepted），其符号定义位于 rustc_span 的 symbol 表。可以推断：

1. E0007 出现于该特性尚不稳定、借用检查对 @ 后子绑定支持不完整的早期阶段，编译器需要专门的错误码来拦截“双重移动”这类非法组合；
2. 随着特性在 1.56 被接受，@ 后的绑定组合（含与切片模式、or 模式、deref 模式的混合使用）已被纳入统一的借用检查，非法移动统一以 E0382 / 常规 borrow 错误报告，E0007 因此退出历史舞台。

用当前测试用例验证 @ 绑定的所有权行为

当前仓库的测试套件完整覆盖了 bindings_after_at 与其他模式特性组合时的借用检查行为，可以直接作为“正确理解与验证方式”的参照：

• tests/ui/borrowck/bindings-after-at-or-patterns-slice-patterns-deref-patterns.rs：系统性地测试 bindings_after_at 与 slice_patterns、or_patterns、deref_patterns 各种组合。其中 bindings_after_at_slice_patterns_move_binding 演示了与 E0007 同构的双重移动场景：

fn bindings_after_at_slice_patterns_move_binding(x: [String; 4]) {
    match x {
        a @ [.., _] => (),
        _ => (),
    };

    &x;
    //~^ ERROR borrow of moved value
}

a @ [.., _] 把整个数组移入 a，其后的 &x 因此报 borrow of moved value——这正是 E0007 场景在当代编译器下的标准报错形态。该文件还覆盖了 ref foo @ [.., ref mut bar] 这类“整体借用与内部可变借用冲突”的变体，对应 E0303 文档中“子绑定必须保证内存安全”的约束。

• tests/ui/drop/dynamic-drop.rs：其中 bindings_after_at_dynamic_init_move、bindings_after_at_dynamic_drop_move 等函数验证 @ 绑定与动态初始化/析构（dynamic init/drop）交互时的移动语义，证明该语法在 drop 检查路径中同样被正确建模。

遇到“双重移动”模式时的改写策略

综合 E0007、E0303 文档与当前源码、测试证据，处理 match 中 @ 绑定引发的所有权冲突有明确的策略：

1. 整体绑定改借用：若不需要真正拿走整个值，把 op_string @ Some(s) 写成 ref op_string @ Some(s)（或 ref mut），让 op_string 持有 &Option<String>，与内部 s 的所有权移出不冲突；
2. 只保留一条移动路径：若确实需要整体所有权，就放弃内部按值绑定，改用 op_string.0 / op_string.as_ref().unwrap() 等方式在分支内按需取引用；
3. 内部值需要独立拥有：对 String 这类 Clone 类型使用 .clone()，或让子绑定先移出后再重构外层（let op_string = Some(s) 形式）；
4. 共享所有权场景：按 E0382 文档 的建议，用 Rc / RefCell 引入运行时共享可变性。

小结与延伸阅读

• E0007 报告 match 分支绑定要求同一值被移动进多个位置、违反唯一所有权的非法组合，典型触发形式为 op_string @ Some(s)（Option<String> 的整体移动与内部 String 的部分移动冲突）；
• 该错误码已由当前编译器停止发出，同样的代码现在报告 E0382（use of moved value），排查时应按 move 语义冲突处理；
• 相关的历史错误码 E0303 处理 @ 子绑定的内存安全检查，其“改写为引用绑定”的建议至今仍是通用解法；
• 语法特性 bindings_after_at 已随 Rust 1.56.0 被接受，可参考 accepted 特性列表 与 borrowck 组合模式测试 了解其在当前编译器中的完整行为边界。

延伸阅读：E0303 错误码文档、E0382 错误码文档、dynamic-drop 测试。