Rust 编译器稳定性保证体系全解从 RFC 1105/1122 到内部组件豁免清单【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rustRust 以稳定压倒一切著称任何进入 stable 的语法、标准库 API 和行为都意味着长期的向后兼容承诺。本文以 rustc 开发者指南中的 stability-guarantees 文档 为骨架系统梳理这套稳定性保证体系的两大制度基石RFC 1105 API 演化与 RFC 1122 语言语义化版本、语言/库特性的双轨稳定化流程、破坏性变更的处理边界以及被明确排除在稳定性承诺之外的内部基础设施清单。读完本文你将完整掌握 Rust 编译器稳定性的运作机制、相关属性注解的语义以及如何在源码层面追踪稳定化流程的实际落点。稳定性保证Rust 项目的一份公开承诺rustc-dev-guide 中的 stability-guarantees.md 是整个稳定性知识体系的总入口。它并不重复实现细节而是以路线图的形式给出四类关键资源的定位两份 RFC定义稳定性策略的正式制度文本权威博客文章阐释稳定性理念的历史背景rustc-dev-guide 内部专题分别讲解库特性、语言特性的稳定化操作以及什么算 Bug 修复的判定标准豁免清单Exemptions明确哪些内部基础设施即便被外部复用也不提供任何稳定性保证。Rust 团队早在 2014 年就提出Stability as a Deliverable稳定性即交付物的理念稳定不是工程的副产品而是与性能、内存安全同等重要的产品交付属性。这一理念最终落实为两套具体机制——通过#[stable]/#[unstable]属性控制 API 可用性的属性体系以及通过 feature gate 控制语言语法开关的特性门控体系。两大基础 RFC稳定性的制度起点RFC 1105API 演化API EvolutionRFC 1105 是 Rust 1.0 发布前最重要的设计文档之一它为标准库 API 的演化确立了核心规则稳定性是默认状态进入 stable 的 API 不得以破坏性方式变更破坏性变更需要正式流程任何可能破坏既有代码的变更都必须经过讨论、评估与批准用属性标注状态#[stable]、#[unstable]、#[deprecated]成为表达 API 状态的一等公民语法这一机制至今仍是标准库稳定性工作的基石。RFC 1122语言语义的语义化版本Language SemverRFC 1122 将语义化版本的思想从版本号层面下沉到语言语义层面它回答了一个关键问题什么样的破坏性变更是被允许的RFC 1122 给出的三类豁免情形至今仍定义着编译器团队可接受的破坏性变更边界详见 bug-fix-procedure.md健全性修正Soundness changes修复类型系统暴露出的安全漏洞编译器 BugCompiler bugs编译器未实现 RFC 或语言团队决策中规定的语义未定义语义的澄清Underspecified semantics编译器行为不一致、且此前从未有过正式裁定的灰色地带。值得注意的是RFC 1122 并没有定义何时允许破坏性变更它只是给出判定条件真正的操作流程crater 影响评估、未来兼容 lint、跟踪 issue则由 RFC 1589 及其落地文档 bug-fix-procedure.md 承接。语言特性的稳定化流程语言特性如pub(restricted)、async fn in trait走的是 stabilization-guide.md 描述的流程其核心是一个完整的提案-评审-门控-放行链条编写 RFC如需若特性源自语言实验lang 团队通常要求在稳定化前先接受 RFC准备文档 PR更新 Reference、The Book 等文档删除 Unstable Book 中对应的特性门控页面其中 Reference 必须由 lang-docs 团队审核批准撰写稳定化报告基于仓库内的稳定化报告模板总结自 RFC 接受以来的设计决策、偏差与贡献者工作提交稳定化 PR核心工作包括三部分——移动 feature gate 条目在 compiler/rustc_feature/src/unstable.rs 的declare_features!宏中找到对应条目将其从unstable状态改写为accepted并移入 compiler/rustc_feature/src/accepted.rs// 稳定化前unstable.rs (unstable, pub_restricted, CURRENT_RUSTC_VERSION, Some(32409)), // 稳定化后accepted.rs (accepted, pub_restricted, CURRENT_RUSTC_VERSION, Some(32409)),注意即使文件中存在历史版本号新条目也应写CURRENT_RUSTC_VERSION占位符由发布流程自动替换为实际版本移除代码库中的 feature 用法将#![feature(XXX)]改为#![cfg_attr(bootstrap, feature(XXX))]使 stage1 仍能使用该特性因为当前 beta 尚未稳定它移除门控检查删除 compiler/rustc_ast_passes/src/feature_gate.rs 中类似gate_all!(pub_restricted, ...)的检查或将if self.tcx.features().xxx() { /* */ }这类条件判断直接改写为恒真的代码块团队提名与 FCP在稳定化 PR 上 CCrust-lang/lang及相关子团队由团队成员发起rfcbot fcp merge进入最终评议期FCP无新异议后合入。这套流程在源码中的落点非常清晰compiler/rustc_feature/src/目录集中管理着所有 feature gate 的生命周期状态unstable / accepted / removed。库特性的稳定性属性体系标准库 API 的稳定性由 stability.md 专题完整覆盖它也是 stability-guarantees.md 指向的最核心操作文档。核心属性#[unstable]与#[stable]#[unstable(feature foo, issue 1234, reason lorem ipsum)] #[stable(feature foo, since 1.420.69)]#[unstable]标记的条目即使在 nightly 上也必须搭配#![feature(...)]才能使用该限制仅作用于 crate 边界定义方 crate 内部可自由使用issue字段必填指向该特性的跟踪 issue极少数无合适编号的情况使用issue noneunstable具有传染性标记在模块上时其下所有子条目默认不稳定可再用#[stable]单独放行某些子条目——机制上与pub的可见性传播类似#[stable]标记的条目允许在其函数体内使用 unstable 内部实现即稳定外壳 不稳定内脏重命名特性时可用old_name old_name生成友好的迁移错误提示。在仓库中可以直接找到大量实战例证例如 library/std/src/backtrace.rs 中#[rustc_const_stable(feature backtrace, since 1.65.0)]展示了标准库条目如何声明其 const 求值能力已随 1.65.0 稳定。const 稳定性递归检查的特殊体系const fn的稳定性比普通 API 更严格因为它涉及编译期求值路径#[rustc_const_unstable(...)]接口与#[unstable]相同用于标记函数的 constness 尚未稳定。它仅在三种场景下需要const fn使用了不稳定语言特性或 intrinsic、const fn已#[stable]但暂不承诺 const 稳定、需要更换调用 const-unstable intrinsic 所需的 feature gate#[rustc_const_stable(feature foo, since ...)]声明 constness 稳定递归性const 稳定性是递归强制的——#[rustc_const_unstable]的函数不能从稳定代码中被间接调用以防不稳定编译器实现细节泄漏到稳定代码、或把不完整实现的意外行为锁死为长期承诺#[rustc_const_stable_indirect]加在rustc_const_unstable函数上使其可被rustc_const_stable函数调用意味着实现层面已就绪仅因 API 考量暂未 const 稳定lang item 也应添加此属性避免编译器合成的 const 调用绕过递归规则#[rustc_allow_const_fn_unstable]用于已知必定稳定、或存在稳定回退方案的场景允许在稳定const fn体内使用特定不稳定特性——新增该属性必须通知 rust-lang/wg-const-eval#[rustc_intrinsic_const_stable_indirect]标记 intrinsic 已可供公开稳定函数使用添加需经 t-lang 与 wg-const-eval 双重批准。宏与默认实现的稳定性#[allow_internal_unstable(feature1, feature2)]允许稳定的标准库宏在其展开体中即调用点暴露的位置使用指定不稳定特性但若宏在 const 上下文调用rustc_const_unstable函数即便有此属性也仍会被拒绝需为函数添加#[rustc_const_stable_indirect]兜底#[rustc_default_body_unstable(...)]标记 trait 中某条目的默认实现为不稳定——外部用户可通过显式提供方法体来稳定实现该 trait或开启对应#![feature]使用默认实现#[unstable_feature_bound(foo)]配合#[unstable]使用将稳定类型 × 稳定 trait 的 impl标记为不稳定适用于impl、自由函数与 trait 三类条目。基础设施约束与废弃机制staged_api任何使用#[stable]/#[unstable]的 crate 必须在 crate 根声明#![feature(staged_api)]deprecated标准库中的废弃与用户代码几乎一致但有两个差异——since字段会被编译器与当前 rustc 版本比对若指向未来版本则触发默认allow的deprecated_in_futurelint标准库多数位置通过#![warn(deprecated_in_future)]提升为警告suggestion字段提供机器可应用的修复建议使用时需在 crate 根开启#![feature(deprecated_suggestion)]#[deprecated( since 1.38.0, note explanation for deprecation, suggestion other_function )]移除特性被移除的特性应使用#![unstable_removed(feature foo, reason ..., link ..., since ...)]生成高质量错误信息其中link指向移除原因的最相关信息issue、评论或 PR。稳定化库特性的标准步骤stability.md 给出了可复制的操作清单请T-libs成员在跟踪 issue 上发起 FCPdisposition-merge并等待完成将#[unstable(...)]改为#[stable(since CURRENT_RUSTC_VERSION)]从测试、doc-test 及编译器/工具代码中移除#![feature(...)]若是const fn补充#[rustc_const_stable(since CURRENT_RUSTC_VERSION)]若暂不 const 稳定则为新 feature gate新跟踪 issue添加#[rustc_const_unstable(...)]向 rust-lang/rust 提交 PR添加T-libs标签并链接跟踪 issue注明 Closes #XXXXX。什么算 Bug 修复破坏性变更的处理边界稳定性承诺不等于永不改变关键在于改变要有可控的过渡路径。bug-fix-procedure.md 基于 RFC 1589 定义了标准流程核心原则是先警告、后报错绝不突然断裂。标准的破坏性变更流程为crater 运行用改动后的编译器批量编译 crates.io 上的全部 crate 与大量公开仓库评估影响面若受影响项目总数非根错误数少于 10可考虑直接报错建立专属跟踪 issue聚焦用户必须如何修改代码作为反馈收集点先发未来兼容 lint 警告在 compiler/rustc_lint/src/builtin.rs 中通过declare_lint!定义带future_incompatible元数据的 lint并在 compiler/rustc_lint/src/lib.rs 中注册警告不现实时则给出指向跟踪 issue 的精准错误并主动向受影响 crate 提交修复 PR稳定化变更在外部世界至少运行一个发布周期后经 FCP 将警告转为硬错误或回滚、或延期。判定什么算 Bug 修复的三类边界健全性修正、编译器 Bug、未定义语义澄清已在 RFC 1122 一节详述此处不再重复。豁免清单内部基础设施不提供稳定性保证stability-guarantees.md 特别强调即便某些内部基础设施可以被外部复用它仍被视为内部组件不附带任何稳定性保证。该清单非穷尽目前明确列出的是The CLIs and environment variables used byremote-test-client/remote-test-server在仓库中这两个工具的实现分别位于 src/tools/remote-test-client 与 src/tools/remote-test-server。它们是 Rust 团队在模拟器/远程设备上运行测试的基础设施client 通过 TCP 连接 server负责推送构件并远程执行测试还内置了 QEMU 与 Android 模拟器的启动支持。从源码结构看其无保证体现在环境变量随时可能变更client 依赖TEST_DEVICE_ADDR默认127.0.0.1:12345与TEST_DEVICE_CONNECT_TIMEOUT_SECONDS默认 30 分钟等环境变量src/tools/remote-test-client/src/main.rsCLI 参数是内部协议client 支持spawn-emulator、push、run等子命令server 支持--bind IP:PORT、--sequential、--batch、-v/--verbose等参数src/tools/remote-test-server/src/main.rs其子命令、参数名与默认绑定地址QEMU 场景下为10.0.2.15:12345完全以 CI 内部需求为准不构成任何对外契约。因此任何依赖这些工具 CLI 或环境变量的第三方集成都必须自行跟随 rustc 仓库的演进维护不能指望语义化版本承诺。结语稳定性的三个层次纵观整套体系Rust 的稳定性承诺呈现出清晰的层次结构语言与库 API最高保证由 RFC 1105/1122 定义边界由#[stable]/#[unstable]属性与 feature gate 双轨管理稳定化必须走 FCP 等正式流程破坏性变更有条件允许仅限健全性修正、编译器 Bug 修复、未定义语义澄清三类且必须经过 crater 评估、跟踪 issue、未来兼容 lint 的渐进过渡内部基础设施零保证remote-test-client / remote-test-server 等工具虽然代码开源、可被复用但 CLI 与环境变量不提供任何稳定性承诺。理解这套分层既是使用 Rust 生态的安全感来源也是贡献者参与 rustc 开发、提交稳定化 PR 时必备的流程地图——从 stability-guarantees.md 出发顺着 stability.md、stabilization-guide.md 与 bug-fix-procedure.md 三条支线即可掌握稳定化的全部实操细节。【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rust创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考