Rust - RFC 2803 target_tier_policy

功能名称： target_tier_policy开始日期：2019-09-20RFC PR: rust-lang/rfcs#2803

摘要

本 RFC 对每个目标支持层级的要求进行了规范，并说明了将目标提升到不同层级的流程。

动机

Rust 开发者经常会在 Rust 编译器中实现新目标（target），而负责审查这些新目标相关 Pull Request 的审查者，也需要有一套清晰、一致的政策可以引用，用于接受或拒绝这些目标。目前，单个审查者并不清楚应该适用怎样的整体政策，也不清楚是应该单独判断还是交由 Rust 治理团队决定。

Rust 开发者经常会询问如何将现有目标提升到 tier 2（特别是如何通过 rustup 获取），偶尔也会问如何添加新的 tier 1 目标。而 Rust 项目并没有明确的目标层级（target tier）政策。大家不仅不知道具体规则，也不知道该向谁咨询或从哪里着手。

详见 https://doc.rust-lang.org/nightly/rustc/platform-support.html，了解更多关于目标和层级的信息。

一旦本 RFC 被采纳，政策部分应与 https://doc.rust-lang.org/nightly/rustc/platform-support.html 一同发布于官方文档的“目标层级政策”部分；本 RFC 并非最新目标层级政策的权威归属地。

指导性说明

Rust 提供三种目标支持层级：

对 tier 3 目标，Rust 不做任何保证；这些目标存在于代码库中，但可能编译通过也可能不通过。Rust 的持续集成（CI）会确保 tier 2 目标始终能构建，但可能不会通过测试。Rust 的持续集成会确保 tier 1 目标始终能构建且通过所有测试。

添加新的 tier 3 目标要求极低，主要关注点是避免对 Rust 其他开发造成干扰。

tier 2 和 tier 1 目标会对 Rust 项目开发者整体带来一定工作量，为了避免目标被破坏。这些更高层级的目标也会促使 Rust 社区更愿意在各自的 crate 中支持这些目标（尽管不是强制）。因此，这些层级要求目标维护者持续投入相应精力，以证明其价值并尽量减少对 Rust 开发进程的干扰。

参考性说明

Rust 提供三种目标支持层级：

对 tier 3 目标，Rust 不作任何保证；这些目标存在于代码库中，但可能无法构建。Rust 的持续集成会确保 tier 2 目标始终可构建，但可能不会通过测试。Rust 的持续集成会确保 tier 1 目标始终能构建且通过所有测试。

本政策定义了在特定支持层级下接受目标的要求。

每一层级都在前一层级要求的基础上递进，除非被更强的要求覆盖。tier 2 和 tier 1 目标还可以提供主机工具（如 rustc、 cargo），对这些工具的支持有额外补充要求。如目标为 tier 2 或 tier 1，但未提供主机工具，则不必满足这些附加要求。

每一层级的政策也记录了必须批准该层级目标的 Rust 治理团队。相关团队负责根据这些要求及自身判断对目标进行评审，必要时可提出额外要求，包括主观性要求（以应对本政策未预见的问题）。这些额外要求之后也可能成为政策内容的补充。

虽然这些标准试图详尽记录政策，但最终政策仍依赖于人工判断。目标必须满足这些要求的精神实质，由批准团队自行裁量。审查者和团队成员在评估目标及目标相关补丁时，应始终运用最佳判断力，评估工作质量和目标对 Rust 项目的适宜性。本政策及任何目标相关决定均不对任何方构成强制性约束或禁止权（estoppel）。

在提交 issue 或 PR 以引入或提升目标之前，该目标应已满足对应层级的全部要求。当然，现有目标维护者可用 issue（无论是在 Rust 仓库还是其他地方）追踪未满足的要求；但在正式提出引入或提升目标前，应确保所有要求已达成。建议目标提案在说明如何满足要求时直接引用对应条款。

所有受支持目标及其层级（“tier 3”、“tier 2”、“tier 2 with host tools”、“tier 1”、“tier 1 with host tools”）会被记录在官方页面，如 https://doc.rust-lang.org/nightly/rustc/platform-support.html。

需要注意的是，目标必须先获得下一级别的批准，并在该层级保持合理时长，方可提出晋升到更高层级的提案；即便目标已同时满足多个层级的要求也如此。本政策将“合理时长”的具体解释交由批准团队裁量，团队可根据对目标的信心及其在当前层级的实际表现调整所需时间。通常，在目标晋升的过程中应经历多个 Rust 稳定版发布周期。

目标在 Rust 稳定版中的可用性或层级并不构成未来可用性或层级的硬性稳定性保证。支持层级越高，表明对目标的承诺也越大；在评估是否降级或移除稳定版目标时，会充分考虑这一承诺和潜在影响。目标的提升或降级一般不会影响已有的稳定版，只影响当前开发和未来发布。

在本政策中，“必须（must）”和“不得（must not）”表示目标必须满足的绝对要求；“应该（should）”和“不应该（should not）”表示几乎总是适用的要求，但批准团队可酌情豁免；“可以（may）”表示完全可选，不具指导或建议意义。该用语基于 IETF RFC 2119。

Tier 3 目标政策

在此层级，Rust 官方对目标不提供支持，因此对目标的引入仅设置极小要求。

新 tier 3 目标须由编译器团队成员根据这些要求评审并批准。评审者可选择通过重大变更提案（MCP）征求更广泛的团队共识。

对影响其他目标共享代码（不仅是目标专属代码）的目标或补丁，须由相关团队评审并批准。

tier 3 目标需指定一位或多位开发者为“目标维护者”，以便在相关问题出现时可 CC 他们（具体机制可能随时间演进）。目标命名应与现有目标保持一致，如为同一 CPU 或 OS 应沿用已有名称。通常应采用生态系统（如其他工具链）通用命名，除非有充分理由偏离。目标命名一旦确定，变更极具破坏性，尤其对高层级目标，因此即使是 tier 3 目标，命名也应慎重。 目标命名不应造成多余的困惑或歧义，除非为兼容生态系统所必需。例如，若目标名极易导致误解，应做更改或补充以消除歧义。 tier 3 目标可以有特殊的构建或使用要求，但不得给 Rust 项目、开发者或用户带来法律问题或苛刻法律条款。 不得引入许可协议不兼容的问题。加入 Rust 仓库的内容必须采用标准 Rust 许可（MIT OR Apache-2.0）。目标不得导致为其他主机编译的 Rust 工具或库（包括交叉编译）依赖任何比 Rust 许可政策更严格的新依赖，无论是 Rust crate 还是本地库/二进制。即，目标的引入不得使安装或运行 Rust 或其工具的用户面临任何新许可要求。若目标支持构建主机工具（如 rustc 或 cargo），则这些主机工具不得依赖专有（非 FOSS）库，除非是主机平台常见的运行时库。例如，目标的 rustc 可依赖常见专有 C 运行库或控制台输出库，但不得依赖专有代码生成或优化库。虽然 Rust 许可允许此类组合，但 Rust 项目不在其范围内维护此类组合，即使是 tier 3。目标不应要求专有组件才能链接成可用二进制或库。“苛刻”一词有主观性。至少包括但不限于：保密协议、竞业禁止、贡献者许可协议（CLA）、“仅限非商业/研究”等条款、针对特定 Rust 开发者雇主/雇佣状态的要求、可撤销条款、造成 Rust 项目或其开发者/用户承担责任的要求、影响其生计或发展前景的要求等。 本政策及任何目标决策均不对任何方构成强制性约束或禁止权（estoppel）。如批准团队成员同时是目标维护者，或有影响其决策的法律/雇佣要求，必须回避该目标层级审批，但可参与讨论。 该条款不影响在显式合同或工作协议中引用本政策部分内容（如为目标实现或维护），其目的是确保审批人可自由裁量，无需担心法律威胁或义务，哪怕涉及主观判断或超出政策明文要求。 tier 3 目标应尽量实现尽可能多的标准库功能（如大多数目标的 core，支持动态内存分配的 alloc，有操作系统或等效系统功能的 std），但可因目标限制而未实现某些代码。PR 作者无义务因 tier 3 目标未实现部分标准库功能而避免调用相关部分。目标需为 Rust 社区提供文档，说明如何为该目标构建（优先使用交叉编译）。若目标支持测试（即使无法通过），也需说明如何运行测试（优先用模拟器，否则需专用硬件）。tier 3 目标不得给 PR 作者或其他开发者带来维护负担。不得因 tier 3 目标在 PR 中发布评论（自动或手动）而阻塞 PR，也不得向 PR 作者或相关人员发送自动消息或通知（包括 @），除非对方主动订阅。 通过 issue/PR tracker 产生的反向链接在合理范围内不算违规。但即使在其他仓库，也不得向未主动订阅的 PR 参与者发送通知。 添加/更新 tier 3 目标的补丁不得破坏现有 tier 2 或 tier 1 目标，且不得在未经编译器团队或其他 tier 3 目标维护者批准的情况下，故意破坏其他 tier 3 目标。 特别是在处理密切相关目标时，如同一架构的不同变种，避免无条件使用其他变种不具备的特性，应采用条件编译或运行时检测等方式，确保每个目标只运行其支持的代码。

如 tier 3 目标不再满足要求、维护者不再有兴趣或精力、长期无活动且无法构建，或移除该目标有助于提升 Rust 代码质量，可通过 PR 移除，并 CC 目标维护者（及曾参与过的人员），征询改进意愿。

Tier 2 目标政策

在此层级，Rust 项目保证目标能构建，并会拒绝在该目标上无法构建的补丁。因此，需要确保目标不会阻碍 Rust 项目正常推进。

新 tier 2 目标须由编译器团队根据这些要求审核批准，可通过重大变更提案（MCP）进行。

此外，基础设施团队须批准目标集成到 CI 及相关要求。此过程可在将目标添加到 CI 的 PR 中完成，或由成员报告团队讨论结果。

tier 2 目标须对除维护者以外的用户有价值（可以是小众目标，但不能只对封闭群体有用）。tier 2 目标必须有至少两人的维护团队，能协助解决目标专属的构建问题，必要时参与目标相关的语言或库实现细节。 目标维护团队不仅需修复目标专属问题，还应借此机会教育 Rust 社区提升可移植性，并完善目标文档。 目标不得给非专注于该目标的 Rust 开发者带来不合理负担。开发者应避免无谓破坏 tier 2 目标，但无需精通所有 tier 2 目标，也无需为所有 tier 2 目标提供专属实现。目标需为 Rust 社区提供文档，说明如何通过交叉编译构建目标，及如何运行目标测试。文档应尽量介绍如何用模拟器运行 Rust 程序和测试，若无法模拟，则需说明如何获取和使用物理硬件、云服务等资源。目标需记录对 CPU、操作系统、库、运行环境等的基础期望（如版本、特性）。若引入的新 tier 2 以上目标与现有目标仅在基础期望（如 CPU/OS 版本）不同，须向批准团队说明为何有必要单独设立该目标。 若社区有意修改目标的基础期望，或将目标拆分为多个不同基础期望的新目标，则处理方式与目标晋升、降级或移除一致，均需同等审批。 例如，若某 OS 版本已过时且不再支持，可提升目标对 OS 版本的基础要求（视为移除旧版目标），或为旧版单独设立低层级目标（视为降级），均需合理说明。 tier 2 目标不得有大量未实现或存根的 core 或标准库部分，除非在该目标上根本无法实现。 若某特性未来可能支持，可根据目标与 Rust 的协同开发进展，逐步完善。特例：若某目标仅与现有 tier 1 目标不同在基础期望（如 OS/CPU 版本），且主要用于 no_std 场景，可提出作为不带 std 的 tier 2（但不得晋升更高层级），以减轻支持负担。此类目标会额外考察其价值。 目标的代码生成后端不应有破坏 Rust 安全属性的缺陷，评判权归编译器团队。若不满足，必须在目标列表及测试套件中明确记录，并获得团队认可。 例如，若 Rust 依赖特定代码生成特性防止栈溢出，则目标需支持该特性。若 Rust 编译器引入新安全属性，团队会判断是“尽力而为”还是“所有目标必须支持”。如为后者，现有目标需实现或记录缺失。 若目标支持 C 代码且有可互操作的 C 调用约定，Rust 目标须通过 extern "C" 支持该平台 C 调用约定（但无须设为默认）。目标需能在 CI 稳定构建所有 Rust CI 认定为必需的组件。批准团队可要求在 CI 通过子集测试（如能构建“hello world”，或 ./x.py test --no-run 等冒烟测试）。特别是对主机工具或关键测试，可能要求更多。目标在 CI 的构建时间不得显著超过当前最慢目标，也不应显著增加 CI 维护负担。此为主观判断，会考虑目标重要性。tier 2 目标应尽量支持交叉编译。即使支持主机工具，也不应强制将目标作为主机进行构建。除 tier 3 法律要求外，由于 tier 2 目标通常需构建和分发二进制文件，其引入和分发不得对 Rust 项目成员（包括基础设施和 CI 运营者）带来苛刻许可要求。此为主观判断，需批准团队评估。 特例：若目标主要用于构建受“copyleft”条款约束的 FOSS 项目（如内核模块、插件），则标准库可受 copyleft 约束，只要遵守 Rust 现有源码分发模式。但加入 Rust 仓库的内容仍需采用标准许可。 tier 2 目标不得要求 PR 作者或其他开发者确保目标测试通过。不得因目标测试失败在 PR 中评论阻塞，也不得向相关人员发送自动消息或通知，除非对方主动订阅。 issue/PR tracker 产生的反向链接在合理范围内不算违规，但不得向未主动订阅的 PR 参与者发送通知。 目标维护者应定期为目标运行测试套件，并及时修复测试失败。所有 tier 3 要求同样适用。

如 tier 2 目标不再满足要求，可降级或移除。降级/移除提案会 CC 目标维护者，并在正式发布前广泛通知社区（具体周期视情况而定）。

某些情况下，如目标维护者未及时响应，Rust 团队可暂时在夜间版禁用部分目标以推动尚未支持的特性（如引入 u128/ i128）。此类 PR 会通知并协作目标维护者，并优先在新开发周期初实施，以便维护者有时间更新目标。若未及时更新，可能在下个稳定版降级或移除该目标。

Tier 2 带主机工具

部分 tier 2 目标可为主机构建二进制工具（如 rustc、 cargo），允许其用作开发平台，而非仅为编译目标。

带主机工具的新 tier 2 目标需由编译器团队审核批准，可通过 MCP 进行。

基础设施团队需批准主机工具集成到 CI 及相关 CI 要求。可在添加主机工具到 CI 的 PR 中完成，或由成员报告团队讨论结果。

依据目标、能力、性能及工具使用可能性，tier 2 目标主机工具可仅包含 rustc/ cargo，也可包括 clippy、 rustfmt 等。主机工具审批会考虑构建和存储等开销。主机工具须对除维护者以外的用户有直接价值（不能仅服务于闭环群体）。此条独立于 tier 2 要求单独评估。 “直接价值”指不能仅因主机工具能帮助维护者更易分发目标而论证，其本身须对他人有用。 主机工具需有合理的实际使用预期，不可仅为“证明能用”而存在。主机工具需能在 CI 稳定构建和运行（CI 认定为必需的组件），但不强制通过测试。主机工具构建时间不得显著超过其他目标，也不应显著增加 CI 维护负担。主机工具应提供与其他目标实质一致的体验，受合理目标限制。 若需对现有工具添加重大接口变更或目标专属接口，须通过对应工具团队（如 RFC/MCP）审批，且需具有可推广到类似目标的设计。例如，如目标运行在沙箱环境，可能需调整文件、工具调用等以适应，但不得擅自引入独立接口。 若平台主机工具需签名等认证（如运行未签名二进制需“开发者模式”或额外确认），Rust 项目自动化构建须能自动签名，无需维护者或第三方手动介入。流程须获基础设施团队认可。 可允许基础设施团队偶尔手动操作，如注册或续签密钥。相关流程须获基础设施团队认可。如流程需签署法律协议，协议可撤销，也可收取象征性费用，但不得苛刻，亦须获基础设施团队认可。协议若变更，可能导致目标不再满足要求。签名流程须对公众开放，不能仅供 Rust 项目专用。此要求旨在保障 Rust 构建（包括 nightly）能便捷满足用户运行主机工具的需求。 提供主机工具不免除应支持交叉编译的要求。所有 tier 2 要求同样适用。

如目标同时满足全部要求，可直接从 tier 3 晋升到 tier 2 带主机工具，但这样做可能更复杂，建议优先成为 tier 2 再扩展主机工具。

Tier 1 目标政策

在此层级，Rust 项目保证目标能构建且测试全部通过，并会拒绝在该目标无法构建或测试失败的补丁。对 tier 1 目标要求最高。

新 tier 1 目标须由编译器团队审核批准，并经发布团队确认支持该目标的可行性与价值。典型流程为通过 RFC 联合评审。

基础设施团队须批准目标集成到 CI 及相关要求。可在 CI PR、团队讨论结果或 RFC 中完成。

tier 1 目标需在开发者社区有广泛重大关注，并满足多个生产用户（跨组织/项目）的需求。此为主观要求，由审批团队共识决定。若目标过时或不再满足，可降级或移除。目标维护团队至少包含 3 名开发者。目标需在 CI 稳定构建和测试全部通过（CI 认定为必需组件）。 不得为通过测试而过度禁用测试或测试片段。此为主观要求。若目标不支持主机工具或性能低，基础设施团队可选择交叉编译测试套件并在本地或模拟器运行。审批团队可酌情评估目标及主机工具的可行性。 目标须尽可能完整地提供 Rust 标准库相关功能。例如，如支持动态内存分配，须实现 alloc 及相关数据结构。目标构建和测试所需时间不得显著超过其他目标，也不应显著增加 CI 维护负担。 若因本地或模拟器性能低下导致测试耗时过长，可能无法晋升为 tier 1。 若运行测试套件须额外基础设施（如物理硬件），维护者须为 Rust 项目提供相关资源，并获基础设施团队认可。 资源可用云端、模拟或物理硬件提供。若需模拟器，审批团队须对其准确性有高度信心，模拟与本地执行结果如有差异为高优先级 bug。若无法模拟，需为 Rust 团队成员开发测试提供独占资源（不必持续独占）。CI 资源须为 Rust 项目持续专用。开发测试资源可按需独占。 tier 1 目标不得强制要求签名、验证或其他“认证”二进制。开发者应能在自控系统上自由构建、运行、测试，或向他人分发相关二进制（可允许开启“开发者模式”但不得额外收费或签署苛刻协议）。 Rust 项目可决定提供签名二进制以提升体验，且 tier 2 带主机工具已要求签名机制。但 tier 1 还需确保开发者可自由开发测试目标，不受限于签名等要求。 所有 tier 2 要求同样适用。

tier 1 目标如不再满足要求但仍满足低层级要求，可降级。降级需完整 RFC 流程，并由编译器与发布团队批准。降级方案会广泛通知社区，且通常不会直接移除而是先降级。通知与发布间隔视具体情况而定。

提升 tier 1 目标基础期望（如最低 CPU/OS 版本）需编译器和发布团队批准，并应广泛通知，但未必需完整 RFC。

Tier 1 带主机工具

部分 tier 1 目标可为主机构建二进制工具（如 rustc、 cargo），允许其用作开发平台。

新 tier 1 带主机工具目标需编译器团队审核批准，发布团队确认主机工具的可行性与价值。通常通过 RFC 联合评审。

基础设施团队需批准主机工具集成到 CI 及相关 CI 要求。可在主机工具 CI PR、团队讨论结果或 RFC 中完成。

tier 1 带主机工具目标通常应包含全部扩展工具（如 clippy、 rustfmt），除非有目标专属原因无法支持。 与 tier 2 不同，tier 1 不会仅因某工具不常用而排除之，会在评估是否晋升 tier 1 带主机工具时一并考虑。一般来说，任何 tier 1 带主机工具目标均应与其他该类目标等价提供所有组件。 主机工具审批会考虑构建和存储等开销。主机工具需在开发者社区有广泛重大关注，并满足多个生产用户（跨组织/项目）的需求。此为主观要求，需单独评估。目标可仅具交叉编译兴趣而无本地编译需求，主机工具需求不达标可被单独移除。主机工具需在 CI 稳定构建、运行并通过测试（CI 认定为必需组件）。 不得为通过测试而过度禁用测试或测试片段。此为主观要求。 主机工具构建和测试所需时间不得显著超过其他目标，也不应显著增加 CI 维护负担。 若因性能低下导致测试耗时过长，可能无法晋升为 tier 1 带主机工具。 提供主机工具不免除应支持交叉编译的要求。所有 tier 2 带主机工具要求同样适用。所有 tier 1 要求同样适用。

寻求晋升为 tier 1 带主机工具的目标，通常应已是 tier 2 带主机工具或 tier 1 无主机工具，以简化审批。

除一般降级流程外，tier 1 带主机工具目标如不再满足要求但仍满足低层级要求，可降级（包括仅移除主机工具或降为 tier 2 带主机工具）。降级需完整 RFC 流程，并由编译器与发布团队批准。降级方案会广泛通知社区。

原理与备选方案

每个层级的审批团队设定，出自与各相关团队针对新目标影响的讨论。

多团队审批也可改为核心团队审批，便于流程简化，但会增加协调成本，也可能导致责任分散。也可将团队审批拆分为多 issue 或 rfcbot 投票，以便简化共识检查，但可能增加复杂性并分散讨论。

对目标晋升前的最低时长也可设定明确要求。

层级编号可重新编号，避免“tier 2 with host tools”、“tier 1 with host tools”等表述。但部分目标不会晋升到“tier 1 with host tools”，如此会让其显得“二等”。而且，既有 tier 1/2/3 编号已广泛使用，变更反而增加混乱，收益有限。

先前实践

本政策旨在规范和记录 Rust 对目标和架构的政策。部分政策已在 Rust 平台支持页体现。

未来相关政策扩展可参考其他社区，如 Debian 的 架构政策 和 归档标准。

其他分层目标支持先例包括 Firefox 支持的构建目标、node.js 支持的平台、GHC 的平台支持。

本 RFC 未具体规定如何追踪和联系目标维护者。部分现有 Rust 目标采用“标记团队”支持 rustbot 触发。也可扩展 rustbot，自动在带目标标签的 issue 上 @ 目标团队。

未来展望

未来若更多目标寻求 tier 1，需进一步细化如“支持目标的可行性与价值”等主观要求的评估标准。也应在遇到边缘案例时及时更新政策条款，主观要求应保留，以便灵活裁量。

本政策未解决因目标数量激增而整体带来负担的问题，未来需适时调整。

需改进向下游用户（尤其是间接依赖非 tier 1 目标者）传达 Rust 支持级别的方法，避免期望与实际不符。

本 RFC 给出了目标可用性和层级稳定性的部分指导，未来应进一步完善。

部分现有目标可能未完全符合本政策标准，应对现有目标进行审计。RFC 并不承诺立即完成，但正式确认现有目标的资格有助于消除支持级别的不确定性。采纳后，未按本标准评估的目标应在平台支持页中注明。

未来可能设立专门的法律合规审批机构，并由法律专业人士协助。

原文地址：https://rust-lang.github.io/rfcs/2803-target-tier-policy.html