企业官网建设流程全解析

Rust 编译器错误码 E0547 深度解析：稳定性属性中缺失issue字段的原因、修复与实现原理

【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rust

在编写或使用 Rust 标准库等 crate 的稳定性标注（stability attributes）时，如果在#[unstable]或#[rustc_const_unstable]属性中只写了feature而没有提供issue参数，编译器会报出 E0547 错误。本文基于 Rust 编译器源码仓库中的错误码文档 E0547.md，完整还原该错误的触发场景与修复方式，并结合 稳定性属性解析源码 与 诊断定义 深入讲解这条诊断是如何产生、参数又是如何被校验的，帮助你既能快速修复报错，也能理解 Rust 稳定性机制（staged_api）的底层规则。

E0547 错误概述

E0547 的诊断信息只有一句话：“Theissuevalue is missing in a stability attribute.”（稳定性属性中缺失issue值）。

它对应编译器中的诊断结构体MissingIssue，定义在 rustc_attr_parsing 的 diagnostics.rs 中：

#[derive(Diagnostic)] #[diag("missing 'issue'", code = E0547)] pub(crate) struct MissingIssue { #[primary_span] pub span: Span, }

可以明确看到：

• 错误码固定为E0547，诊断文本为missing 'issue'；
• 该诊断通过#[primary_span]标记出错的属性位置，即报错箭头会精确指向#[unstable(...)]/#[rustc_const_unstable(...)]属性本身。

与它紧挨着的两个近亲错误码也一并列出，方便排查时对照（同样位于 diagnostics.rs）：

另外，错误码的“注册表”位于 rustc_error_codes 的 lib.rs，其中0547被列入error_codes!宏的在用错误码列表，且该文件头部注释说明：每个E****.md文档需要遵循 RFC 1567 的长错误码解释规范，并由 tidy 工具（check_error_codes_docs）检查其与宏列表的一致性。因此你看到的 E0547.md 并不是普通说明文档，而是与编译器错误码一一对应、受 CI 约束的正式错误解释。

触发 E0547 的错误代码示例

以下是错误码文档中给出的、会触发 E0547 的完整示例：

#![feature(staged_api)] #![allow(internal_features)] #![stable(since = "1.0.0", feature = "test")] #[unstable(feature = "_unstable_fn")] // invalid fn _unstable_fn() {} #[rustc_const_unstable(feature = "_unstable_const_fn")] // invalid const fn _unstable_const_fn() {}

三点说明：

1. 前提条件：staged_api是用于给标准库/编译器内部 crate 打稳定性标注的特性门，必须在 crate 根上用#![feature(staged_api)]开启；internal_features允许在 crate 内使用其他不稳定特性，这里用#![allow(internal_features)]放开。
2. 错误原因：两个被标注项的稳定性属性都只提供了feature，而没有提供issue，这正是 E0547 的触发条件。
3. 涉及两类属性：普通的#[unstable(...)]与常量语境专用的#[rustc_const_unstable(...)]走的是同一条参数校验路径，因此两者缺issue都会报同一个错误码。

修复方式：补上issue字段

修复方法只有一条：为属性补充issue参数。文档给出的修正后示例为：

#![feature(staged_api)] #![allow(internal_features)] #![stable(since = "1.0.0", feature = "test")] #[unstable(feature = "_unstable_fn", issue = "none")] // ok! fn _unstable_fn() {} #[rustc_const_unstable( feature = "_unstable_const_fn", issue = "none" )] // ok! const fn _unstable_const_fn() {}

其中issue = "none"是一个合法取值，表示该不稳定特性没有对应的跟踪 issue（tracking issue）。

issue参数的完整取值规则

从源码 parse_unstability 的实现可以看到issue参数的完整解析逻辑：

Some(sym::issue) => { insert_value_into_option_or_error(cx, param, &mut issue, word.unwrap())?; // These unwraps are safe because `insert_value_into_option_or_error` ensures the meta item // is a name/value pair string literal. issue_num = match issue.unwrap().as_str() { "none" => None, issue_str => match issue_str.parse::<NonZero<u32>>() { Ok(num) => Some(num), Err(err) => { cx.emit_err(diagnostics::InvalidIssueString { span: param.span(), cause: diagnostics::InvalidIssueStringCause::from_int_error_kind( param.args().as_name_value().unwrap().value_span, err.kind(), ), }); return None; } }, }; }

也就是说issue只接受两类值：

解析失败时的InvalidIssueString诊断同样定义在 diagnostics.rs，会根据IntErrorKind（空字符串、非法数字字符、正/负溢出、零值等）给出不同 label 提示。因此“写了issue但值不对”和“根本没写issue”是两个不同的错误。

而 E0547 本身的触发点正是解析函数末尾的这一行（stability.rs 第 464 行）：

let issue = issue.ok_or_else(|| cx.emit_err(diagnostics::MissingIssue { span: cx.attr_span }));

遍历完所有参数后，如果issue变量仍为None，则以整个属性的 span（cx.attr_span）发出MissingIssue诊断——这与错误提示箭头指向属性整体的行为完全一致。

与feature参数一起看：E0546 / E0547 的判定顺序

同一个parse_unstability函数中，feature的校验逻辑是：

let feature = match feature { Some(feature) if rustc_lexer::is_ident(feature.as_str()) => Ok(feature), Some(_bad_feature) => Err(cx.emit_err(diagnostics::NonIdentFeature { span: cx.attr_span })), None => Err(cx.emit_err(diagnostics::MissingFeature { span: cx.attr_span })), }; let issue = issue.ok_or_else(|| cx.emit_err(diagnostics::MissingIssue { span: cx.attr_span }));

从源码结构看，判定顺序是：先校验feature（缺失 → E0546MissingFeature；不是标识符 → E0546NonIdentFeature），再校验issue（缺失 → E0547MissingIssue）。两者同时缺失时会同时报出两条诊断。此外该函数在参数全部合法后还会检查一点：稳定语言特性不能被用作不稳定库特性（ACCEPTED_LANG_FEATURES命中时发出UnstableAttrForAlreadyStableFeature），这属于更深层的稳定性约束，与 E0547 无直接关系，但说明unstable属性的校验远不止“字段齐全”这一层。

哪些属性会走到这条校验路径

E0547 并非所有稳定性标注都会触发。从 stability.rs 中三个解析器的ATTRIBUTES注册可以梳理出调用关系：

1. StabilityParser（第 69–144 行）：
   • #[stable(feature = "name", since = "version")]：走parse_stability，只要求feature与since，不要求issue，因此#[stable]永远不会报 E0547（缺feature报 E0546）。
   • #[unstable(feature = "name", reason = "...", issue = "N")]：走parse_unstability，issue必选，缺失即 E0547。其参数模板明确写着feature = "name", reason = "...", issue = "N"。
2. ConstStabilityParser（第 220–304 行）：
   • #[rustc_const_unstable(feature = "name", ...)]：同样调用parse_unstability，与#[unstable]共用同一套issue校验逻辑，所以错误示例中的const fn项也会报 E0547。
   • #[rustc_const_stable(feature = "name")]：走parse_stability，同样不涉及issue。
3. BodyStabilityParser（第 182–206 行）：
   • #[rustc_default_body_unstable(feature = "name", reason = "...", issue = "N")]：也调用parse_unstability，参数模板与#[unstable]一致，因此缺失issue时同样会得到 E0547。

三个解析器的属性均标注了unstable!(staged_api)，即只有在开启staged_api特性的 crate 中这些属性才会被接受。这解释了为什么文档示例必须在 crate 根写#![feature(staged_api)]。

此外，parse_unstability中除feature/reason/issue外还接受implied_by与old_name两个可选参数（见 第 442–447 行），出现未识别的参数名则会通过expected_specific_argument提示只接受这五个键。这可以作为排查“属性写对了为什么还不生效”的参考。

Rust 稳定性机制背景：为什么issue是必选的

错误码文档末尾指向了两份延伸阅读：Rust Book 附录 “How Rust is Made and 'Nightly Rust'” 以及 Rustc Dev Guide 的 “Stability attributes” 章节。仓库内对应的开发者文档是 rustc-dev-guide 的 stability.md，其中对issue字段的说明是：

The#[unstable(feature = "foo", issue = "1234", reason = "lorem ipsum")]… Theissuefield specifies the associated GitHub issue number… and all unstable features should have an associated tracking issue. In rare cases where there is no sensible value,issue = "none"is used.

这与源码实现完全呼应：Rust 的 API 分阶段稳定（staged API stability）要求每个不稳定特性都有一个跟踪 issue，作为后续 FCP（Final Comment Period）、稳定化 PR 的锚点；只有极少数没有合理 issue 可引用的场景才允许写issue = "none"。编译器把这条“流程约定”直接硬编码为编译期强制检查，缺失时以 E0547 拒绝通过——这正是该错误码存在的意义。

总结与排查清单

• 错误含义：#[unstable]、#[rustc_const_unstable]或#[rustc_default_body_unstable]属性缺少必需的issue参数，诊断文本为missing 'issue'，错误码 E0547。
• 修复方式：补上issue参数，取值为"none"或正整数 issue 编号字符串，例如#[unstable(feature = "_unstable_fn", issue = "none")]。
• 注意区分：issue值写错（非"none"且非正整数字符串）不会报 E0547，而是报InvalidIssueString；缺少的是feature则报 E0546。
• 实现位置：诊断定义在 compiler/rustc_attr_parsing/src/diagnostics.rs，触发逻辑在 compiler/rustc_attr_parsing/src/attributes/stability.rs 的parse_unstability函数。
• 错误码文档：compiler/rustc_error_codes/src/error_codes/E0547.md，其错误码注册与 tidy 校验规则见 compiler/rustc_error_codes/src/lib.rs。
• 机制背景：稳定性属性的字段约定与 tracking issue 要求见 src/doc/rustc-dev-guide/src/stability.md。

【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rust