Rust 编译错误 E0198 深度解析：为什么 negative impl（负实现）不能标记为 `unsafe`

E0198 是 rustc 在编译期报告的一个错误，核心信息是"负实现不能是 unsafe 的"（negative impls cannot be unsafe）。它属于 rustc 语法检查（AST validation）阶段抛出的诊断错误，本文将以当前仓库（rustc 编译器源码树）中的错误说明文档 E0198.md 为主体，结合其诊断定义源码、触发路径与配套 UI 测试，完整讲解该错误的触发场景、底层原理与修复方式，帮助你理解 Rust 的 trait 极性与 unsafe 语义之间的关系。

错误速览：一条最直接的触发示例

当你在一个 impl 前同时使用了 unsafe 关键字和 !（负实现标记）时，编译器就会报出 E0198。错误说明文档中给出的错误示例为：

struct Foo;

unsafe impl !Clone for Foo { } // error!

其对应的实际 UI 测试位于 tests/ui/error-codes/E0198.rs，测试中使用的是 Send 这一自动 trait，从而把问题隔离得更干净：

#![feature(negative_impls)]

struct Foo;

unsafe impl !Send for Foo { } //~ ERROR E0198

fn main() {
}

根据 tests/ui/error-codes/E0198.stderr 中的期望输出，rustc 产生的完整诊断如下：

error[E0198]: negative impls cannot be unsafe
  --> $DIR/E0198.rs:5:13
   |
LL | unsafe impl !Send for Foo { }
   | ------      -^^^^
   | |           |
   | |           negative because of this
   | unsafe because of this

error: aborting due to 1 previous error

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

可以看到，编译器会用两处辅助 label 分别标出"unsafe 关键字来自这里"和"负实现标记 ! 来自这里"，帮助用户快速定位冲突的两个语法成分。

什么是"负实现"（negative impl）与 trait 极性

要理解 E0198，首先需要理解 Rust 中 impl 的两种极性（polarity）：

• 正实现（positive impl）：最常见的写法，即 impl SomeTrait for SomeType，声明"该类型实现了某个 trait"，并为之提供对应的实现代码。
• 负实现（negative impl）：使用 ! 前缀的写法，即 impl !SomeTrait for SomeType，声明"该类型明确不实现某个 trait"，从而把该类型从该 trait 的实现者集合中排除出去。

从仓库源码看，impl 的极性在 AST 的 Impl 节点中由 ImplPolarity 表达（Negative 表示负实现）。E0198 的检测逻辑正位于语法校验器 compiler/rustc_ast_passes/src/ast_validation.rs 的 visit_item 中：当一个 Impl 同时具有 of_trait: Some(...)、Safety::Unsafe 与 ImplPolarity::Negative 时，即触发错误：

if let (&Safety::Unsafe(span), &ImplPolarity::Negative(sp)) = (safety, polarity) {
    self.dcx().emit_err(diagnostics::UnsafeNegativeImpl {
        span: sp.to(t.path.span),
        negative: sp,
        r#unsafe: span,
    });
}

这段代码清晰地展示了 E0198 的本质判定条件：在 trait 实现（带 of_trait 的 impl）中，unsafe 标记与负极性同时出现。注意这里 unsafe 的优先级高于负实现，编译器先报出 E0198。

为什么负实现永远不需要 unsafe

负实现把一个类型排除在某个 trait 的实现者集合之外。"不能使用某个 trait"本身是一种纯否定的事实声明，不涉及任何需要由实现者额外保证的内存安全不变量，因此它在语义上永远是安全的，永远不需要也不允许标注 unsafe。

这可以从 unsafe impl 的意义反过来理解：Rust 中的 unsafe impl（例如 unsafe impl Send for MyType）表示"实现该 trait 需要承担编译器无法自动验证的安全责任"。而负实现只是声明"该类型不满足/不属于该 trait 的实现范围"，它没有提供任何实现，自然也就不存在需要人工担保的不变量。

E0198 的错误说明文档（即本主题的权威出处）明确指出：

A negative implementation is one that excludes a type from implementing a particular trait. Not being able to use a trait is always a safe operation, so negative implementations are always safe and never need to be marked as unsafe.

该诊断的消息文本定义在 compiler/rustc_ast_passes/src/diagnostics.rs 中：

#[derive(Diagnostic)]
#[diag("negative impls cannot be unsafe", code = E0198)]
pub(crate) struct UnsafeNegativeImpl {
    #[primary_span]
    pub span: Span,
    #[label("negative because of this")]
    pub negative: Span,
    #[label("unsafe because of this")]
    pub r#unsafe: Span,
}

借助 rustc 的 Diagnostic 派生宏，这个结构体同时声明了诊断主文案 negative impls cannot be unsafe、错误码 E0198，以及两处 #[label] 标注，与上文 .stderr 中展示的双 label 输出一一对应。

正确的写法：去掉 unsafe 前缀

修复方式非常简单：负实现是安全的，直接去掉 unsafe 关键字即可。错误说明文档给出的可编译示例为：

#![feature(auto_traits)]

struct Foo;

auto trait Enterprise {}

impl !Enterprise for Foo { }

要点拆解：

1. 定义一个自动 trait（auto trait Enterprise {}）；
2. 用 impl !Enterprise for Foo { } 将 Foo 从该自动 trait 的实现者中排除；
3. 整个声明不加 unsafe。

需要特别留意：错误说明文档明确补充——"负实现目前只允许作用于自动 trait"（negative impls are only allowed for auto traits）。因此示例中 unsafe impl !Clone 除了触发 E0198 外，还会因 Clone 并非自动 trait 而面临额外的限制（文档选择 Clone 仅为展示 unsafe 与 ! 的冲突；而配套的 UI 测试 tests/ui/error-codes/E0198.rs 改用自动 trait Send，以单独且精确地复现 E0198 本身）。

E0198 涉及的两个 unstable feature gate

当前仓库中，与负实现相关的语法仍处于实验阶段，需要通过 feature gate 启用：

• negative_impls：自 Rust 1.44.0 起标记为 unstable（issue #68318），feature gate 声明见 compiler/rustc_feature/src/unstable.rs；
• auto_traits：自 Rust 1.50.0 起标记为 unstable（issue #13231），同在该文件中声明。

在 compiler/rustc_ast_passes/src/feature_gate.rs 中，两者分别有对应的软性门控提示：

• 对 negative_impls：soft_gate_all_legacy_dont_use!(negative_impls, "negative impls are experimental");
• 对 auto_traits：soft_gate_all_legacy_dont_use!(auto_traits, "auto traits are unstable");

这意味着：若要自行复现文首的报错示例，需要像 UI 测试那样在文件头部写入 #![feature(negative_impls)]（见 tests/ui/error-codes/E0198.rs）；若要编写"定义自动 trait + 负实现"的正确示例，则启用 auto_traits feature 即可（对应文档示例的写法）。

相关实现与测试延伸：负实现的真实用途

负实现并非仅为展示错误而生，它在并发安全与孤儿规则相关场景中有真实用途，仓库中保留了大量相关测试可供深入阅读：

• 自动 trait 的推导逻辑（负实现如何影响 Send/Sync 等的自动实现）位于 compiler/rustc_trait_selection/src/traits/auto_trait.rs；
• 负实现与 coherence 检查的交互可参考 tests/ui/coherence/coherence-negative-impls-safe.rs（含可运行通过变体 -rpass）与 tests/ui/coherence/coherence-negative-impls-copy.rs；
• 关于负实现与自动 trait 组合的基础行为，可参考 tests/ui/traits/negative-impls/negative-impls-basic.rs 等测试目录下的用例。

阅读这些测试可以体会到：负实现常被用于"把某个类型从自动 trait（如 Send、Sync）的自动推导中显式排除"，而这类排除声明本身只是安全的类型信息，编译器要求其不含 unsafe 正是对"安全事实声明"与"需要人工担保的不变量"两种语义的严格区分。

小结

• 触发条件：在 impl 前同时书写 unsafe 与 !（负极性），如 unsafe impl !Send for Foo {}，即触发 E0198 "negative impls cannot be unsafe"。
• 根本原因：负实现只是"排除某类型实现某 trait"的安全事实声明，不携带任何需要实现的代码或不变量，故永远不需要 unsafe。
• 修复方法：删除 unsafe 关键字；同时记住负实现目前仅允许用于自动 trait，且相关语法需要 negative_impls / auto_traits 等 unstable feature。
• 代码位置：诊断触发于 compiler/rustc_ast_passes/src/ast_validation.rs（约 1447 行起），消息定义于 compiler/rustc_ast_passes/src/diagnostics.rs，注册于错误码文档 E0198.md，并有 tests/ui/error-codes/E0198.rs 配套测试持续守护该诊断行为。