目标层级策略

目录

• 概述
• 添加新目标
• Tier 3 目标策略
• Tier 2 目标策略
  • Tier 2 与宿主机工具
• Tier 1 目标策略
  • Tier 1 与宿主机工具

概述

Rust 提供了三个层级的目标支持

• Rust 不对 Tier 3 目标提供任何保证；它们存在于代码库中，但可能可以构建，也可能无法构建。
• Rust 的持续集成检查 Tier 2 目标是否始终可以构建，但它们可能通过测试，也可能无法通过测试。
• Rust 的持续集成检查 Tier 1 目标是否始终可以构建并通过测试。

添加新的 Tier 3 目标的要求极低；我们主要关注避免对其他正在进行的 Rust 开发造成干扰。

Tier 2 和 Tier 1 目标给整个 Rust 项目开发者带来了工作负担，以避免破坏目标。更广泛的 Rust 社区也可能更倾向于在其 crate 中支持更高级别的目标（尽管他们没有义务这样做）。因此，这些层级需要目标维护者付出相应的持续努力，以证明其价值并最大程度地减少对正在进行的 Rust 开发的任何干扰。

本策略定义了在给定的支持级别下接受提议目标的必要条件。

每个层级都建立在前一个层级的所有要求之上，除非被更强的要求覆盖。Tier 2 和 Tier 1 的目标也可能提供宿主机工具（例如 rustc 和 cargo）；如果为目标提供宿主机工具，则每个层级都包含一组必须满足的补充要求。Tier 2 或 Tier 1 的目标不是必须提供宿主机工具，但如果提供，则必须满足相应的宿主机工具的附加要求。

每个层级的策略还记录了必须批准在该层级添加任何目标的 Rust 治理团队。这些团队负责根据这些要求及其自身的判断来审查和评估目标。这些团队可能会应用额外的要求，包括主观要求，例如处理本策略未预见的问题。（此类要求随后可能会促使对本策略进行补充。）

虽然这些标准试图记录该策略，但该策略仍然涉及人为判断。目标还必须符合要求的精神，这由批准团队的判断来决定。审查员和团队成员在评估目标和特定于目标的补丁时，应始终使用他们自己最好的判断来评估工作质量以及目标对 Rust 项目的适用性。本策略以及关于目标的任何决定均不构成任何一方的约束性协议或禁止反言。

在提交 issue 或 pull request (PR) 以引入或提升目标之前，目标应已满足相应的层级要求。这并不排除现有目标的维护者使用 issue（在 Rust 仓库或其他地方）来跟踪尚未满足的要求，如果合适的话；但是，在正式提议引入或提升目标之前，它应满足所有必要的要求。目标提案必须逐字引用相应的要求，并在解释目标如何满足这些要求时做出回应。（对于仅声明目标或目标开发者不得做某事的要求，承认该要求就足够了。）

有关所有受支持目标及其相应层级（“tier 3”、“tier 2”、“tier 2 与宿主机工具”、“tier 1”或“tier 1 与宿主机工具”）的列表，请参阅平台支持。

本策略的几个部分要求提供特定于目标的文档。此类文档通常应出现在本 rustc 手册的 platform-support 部分的子目录中，并从平台支持中目标的条目链接过来。使用TEMPLATE.md作为基础，并参阅该目录中的其他文档示例。

请注意，目标必须已获得下一个较低层级的批准，并在该层级花费了合理的时间，然后才能提出晋升到下一个更高层级的提案；即使目标一次满足多个层级的要求，情况也是如此。本策略将“合理的时间”的具体解释留给批准团队；这些团队可以根据他们对目标的信心及其在当前层级中展示的良好记录来调整所需的时间量。至少，在目标的晋升之间通常应发生多个 Rust 稳定版本发布。

目标在稳定 Rust 中的可用性或层级不是关于该目标未来可用性或层级的硬性稳定性保证。更高级别的目标层级是对目标支持的日益增加的承诺，在评估可能降级或移除已成为稳定版本一部分的目标时，我们将考虑该承诺和潜在的中断。目标的晋升或降级通常不会影响现有的稳定版本，只会影响当前的开发和未来的版本。

在本策略中，“必须”和“不得”这两个词指定了目标要符合某个层级资格必须满足的绝对要求。“应该”和“不应该”这两个词指定了几乎在所有情况下都适用的要求，但批准团队可能有充分的理由允许例外情况。“可能”这个词表示完全可选，并不表示指导或建议。此语言基于IETF RFC 2119。

添加新目标

新目标通常从 Tier 3 开始，然后可以稍后晋升。要提议添加新目标，请在rust-lang/rust上打开 pull request

• 将Tier 3 目标策略复制到描述中并填写，请参阅示例。
• 使用模板在 src/doc/rustc/src/platform-support 中为目标添加新的描述。
• 将目标添加到 SUMMARY.md (允许使用通配符) 和 platform-support.md (必须逐字命名所有目标)。链接到创建的描述页面。
• 通过评论确保 pull request 分配给Rust 编译器团队的成员

  r? compiler
  

Tier 3 目标策略

在此层级，Rust 项目不为目标提供官方支持，因此我们对目标的引入设置了最低要求。

提议的新 Tier 3 目标必须由编译器团队的成员根据这些要求进行审查和批准。审查员可以选择通过重大变更提案 (MCP)来衡量更广泛的编译器团队的共识。

提议的目标或特定于目标的补丁，如果实质性地更改了与其他目标共享的代码（不仅仅是特定于目标的代码），则必须在接受之前由该共享代码的相应团队进行审查和批准。

• Tier 3 目标必须有指定的开发者或开发者（“目标维护者”）记录在案，以便在出现与目标相关的问题时抄送他们。（跟踪和抄送此类开发者的机制可能会随着时间的推移而发展。）
• 目标必须使用与任何现有目标一致的命名；例如，与现有 Rust 目标相同的 CPU 或 OS 的目标应使用相同的 CPU 或 OS 名称。目标通常应使用与 Rust 以外的更广泛生态系统（例如其他工具链）中使用的名称和命名约定相同的名称和命名约定，除非它们有充分的理由偏离。更改目标的名称可能会造成很大的破坏，尤其是在目标达到更高层级之后，因此即使对于 Tier 3 目标，正确命名也很重要。
  • 目标名称不应引入不必要的混淆或歧义，除非为了保持生态系统兼容性绝对必要。例如，如果目标的名称极有可能使人们对它的目标形成不正确的信念，则应更改或扩充名称以消除歧义。
  • 如果可能，名称仅使用字母、数字、破折号和下划线。句点 (.) 已知会在 Cargo 中引起问题。
• Tier 3 目标可能具有不寻常的构建或使用要求，但不得为 Rust 项目或 Rust 开发者或用户带来法律问题或施加繁重的法律条款。
  • 目标不得引入许可证不兼容性。
  • 添加到 Rust 仓库的任何内容都必须在标准的 Rust 许可证 (MIT OR Apache-2.0) 下。
  • 目标不得导致为任何其他宿主机（即使在支持交叉编译到目标时）构建的 Rust 工具或库依赖于任何比 Rust 许可政策更宽松的新依赖项。这适用于依赖项是需要添加新的许可证例外（由 rust-lang/rust 仓库中的 tidy 工具指定）的 Rust crate，还是依赖项是原生库或二进制文件。换句话说，目标的引入不得导致安装或运行 Rust 或 Rust 工具版本的用户受到任何新的许可证要求的约束。
  • 编译、链接和为目标发出功能性二进制文件、库或其他代码（无论是在目标本身上托管还是从另一个目标交叉编译）不得依赖于专有（非 FOSS）库。为目标本身构建的宿主机工具可能依赖于平台提供的普通运行时库以及为目标构建的其他应用程序常用的运行时库，但这些库不得是为目标生成代码所必需的；交叉编译到目标根本不得需要此类库。例如，为目标构建的 rustc 可能依赖于常见的专有 C 运行时库或控制台输出库，但不得依赖于专有的代码生成库或代码优化库。Rust 的许可证允许此类组合，但 Rust 项目对在 Rust 本身范围内维护此类组合不感兴趣，即使在 Tier 3 级别也是如此。
  • “繁重”在这里是一个有意的主观术语。至少，“繁重”的法律/许可条款包括但不仅限于：保密要求、竞业禁止要求、贡献者许可协议 (CLA) 或同等协议、“非商业用途”/“仅限研究”/等条款、以任何特定 Rust 开发者的雇主或雇用为条件的条款、可撤销条款、任何为 Rust 项目或其开发者或用户带来责任的条款，或任何对 Rust 项目或其开发者或用户的生计或前景产生不利影响的条款。
• 本策略以及关于目标的任何决定均不构成任何一方的约束性协议或禁止反言。如果批准 Rust 团队的任何成员担任目标的维护者之一，或者有任何可能影响他们关于目标决定的法律或雇佣要求（明示或暗示），他们必须回避关于目标层级状态的任何批准决定，尽管他们可以以其他方式参与讨论。
  • 此要求并不妨碍在本策略中引用部分或全部内容作为明确的合同或工作协议（例如，实施或维护对目标的支持）。此要求的存在是为了确保负责审查和批准目标的开发者或团队不会面临任何法律威胁或义务，从而阻止他们自由地行使此类批准的判断，即使此类判断涉及主观事项或超出这些要求的字面意思。
• Tier 3 目标应尝试实现尽可能多且适当的标准库（大多数目标的 core，可以支持动态内存分配的目标的 alloc，具有操作系统或同等系统提供功能层的目标的 std），但可以留下一些未实现的代码（无论是不可用还是根据需要存根化），无论是由于目标使其无法实现还是难以实现。pull request 的作者没有义务因为 Tier 3 目标未实现标准库的某些部分而避免调用标准库的任何部分。
• 目标必须为 Rust 社区提供文档，解释如何为目标构建，如果可能，使用交叉编译。如果目标支持运行二进制文件或运行测试（即使它们未通过），则文档必须解释如何为目标运行此类二进制文件或测试，如果可能，使用模拟，如果必要，使用专用硬件。
• Tier 3 目标不得给 pull request 的作者或社区中的其他开发者带来维护目标的负担。特别是，不要在 PR 上发布评论（自动或手动），这些评论会因为 Tier 3 目标而使 PR 偏离轨道或建议阻止 PR。除非 PR 作者或其他与 PR 相关的人员选择接收此类消息，否则不要向他们发送关于 Tier 3 目标的自动消息或通知（通过任何媒介，包括通过 @）。
  • 当链接到 issue 或 PR 时，由 issue/PR 跟踪器生成的反向链接（例如那些）不被视为违反本策略，在合理的范围内。但是，此类消息（即使在单独的仓库中）也不得向任何未请求此类通知的 PR 相关人员生成通知。
• 添加或更新 Tier 3 目标的补丁不得破坏任何现有的 Tier 2 或 Tier 1 目标，并且不得在未经编译器团队或其他 Tier 3 目标的维护者批准的情况下故意破坏另一个 Tier 3 目标。
  • 特别是，当处理密切相关的目标时，例如具有不同功能的相同架构的变体时，可能会出现这种情况。避免无条件使用目标的另一个变体可能不具备的功能；根据需要使用条件编译或运行时检测，以使每个目标运行该目标支持的代码。
• Tier 3 目标必须能够使用 rustc 支持的至少一个后端从任何宿主机目标生成汇编代码。（在后端的 fork 中获得支持是不够的，它必须是上游的。）

如果 Tier 3 目标停止满足这些要求，或者目标维护者不再有兴趣或时间，或者目标没有活动迹象并且已经有一段时间没有构建，或者移除目标会提高 Rust 代码库的质量，我们可能会发布 PR 以移除它；任何此类 PR 都将抄送给目标维护者（以及可能以前在该目标上工作过的其他人），以检查他们是否有兴趣改善这种情况。

Tier 2 目标策略

在此层级，Rust 项目保证目标可以构建，并将拒绝无法在目标上构建的补丁。因此，我们设置了确保目标不会阻碍 Rust 项目向前发展的要求。

提议的新 Tier 2 目标必须由编译器团队根据这些要求进行审查和批准。此类审查和批准可以通过重大变更提案 (MCP)进行。

此外，基础设施团队必须批准将目标集成到持续集成 (CI) 中，以及 Tier 2 CI 相关要求。此审查和批准可以在将目标添加到 CI 的 PR 中进行，或者仅由基础设施团队成员报告团队讨论的结果。

• Tier 2 目标必须对除其维护者以外的人员有价值。（它可能仍然是一个小众目标，但它绝不能仅对一个本质上封闭的群体有用。）
• Tier 2 目标必须有一个指定的开发者团队（“目标维护者”）可以咨询特定于目标的构建破坏问题，或者在必要时开发特定于目标的语言或库实现细节。该团队必须至少有 2 名开发者。
  • 目标维护者不仅应修复特定于目标的问题，还应将任何此类问题用作向 Rust 社区普及关于可移植到其目标的信息的机会，并加强目标的文档。
• 目标不得给不专门关注该目标的 Rust 开发者带来不必要的负担。Rust 开发者不应无缘无故地破坏 Tier 2 目标，但不应期望成为每个 Tier 2 目标的专家，也不应期望为每个 Tier 2 目标提供特定于目标的实现。
• 目标必须为 Rust 社区提供文档，解释如何使用交叉编译为目标构建，并解释如何为目标运行测试。如果可能，此文档应展示如何使用模拟为目标运行 Rust 程序和测试，以允许任何人这样做。如果目标无法切实地进行模拟，则文档应解释如何获取和使用物理硬件、云系统或同等设备。
• 目标必须记录其对 CPU、操作系统、库、运行时环境和类似功能的特性或版本的基线期望。
• 如果引入新的 Tier 2 或更高级别的目标，该目标与现有的 Rust 目标相同，只是 CPU、操作系统、库、运行时环境和类似功能的特性或版本的基线期望不同，则提议的目标必须令批准团队满意地记录特定基线期望的差异为何提供了足够的价值来证明单独目标的合理性。
  • 请注意，在某些情况下，根据 Rust 社区内现有目标的使用情况，Rust 开发者或目标的维护者可能希望修改目标的基线期望，或者将现有目标拆分为具有不同基线期望的多个目标。根据本策略，对此类操作的提案将与类似的目标晋升、降级或移除一样对待，需要相同的团队批准。
    • 例如，如果操作系统版本已过时且不受支持，则该操作系统的目标可能会提高其对操作系统版本的基线期望（视为删除与旧版本对应的目标），或者该操作系统的目标可能会将对旧操作系统版本的支持拆分到较低层级的目标中（视为降级与旧版本对应的目标，并且需要证明较低层级的新目标对于旧操作系统版本的合理性）。
• Tier 2 目标不得留下任何 core 或标准库的任何重要部分未实现或存根化，除非它们不可能在目标上得到支持。
  • 处理目标中缺少的功能的正确方法可能取决于目标在未来是否有可能开发该功能。在某些情况下，目标可能会与 Rust 支持一起共同开发，并且随着目标获得支持这些功能的能力，Rust 可能会在该目标上获得新功能。
  • 作为例外，与现有 Tier 1 目标相同的目标，只是操作系统、CPU 或类似功能的基线期望较低，如果目标主要用于 no_std 应用程序，则可以提议将其限定为 Tier 2（但不高于 Tier 2），而无需支持 std，以减轻标准库的支持负担。在这种情况下，对提议目标的价值评估将考虑此限制。
• 目标的代码生成后端不应存在使 Rust 安全属性失效的缺陷，这由 Rust 编译器团队评估。（此要求不适用于代码生成后端提供的任意安全增强或缓解措施，仅适用于确保安全 Rust 代码不会导致未定义行为或其他不健全性所需的那些属性。）如果此要求不成立，则目标必须在其目标层级列表条目中清楚且突出地记录任何此类限制，理想情况下，还应通过测试套件中的失败测试来记录。Rust 编译器团队必须对这些限制与实现必要功能的难度之间的平衡感到满意。
  • 例如，如果 Rust 依赖于特定的代码生成功能来确保安全代码不会溢出堆栈，则目标的代码生成应支持该功能。
  • 如果 Rust 编译器引入了新的安全属性（例如通过编译器后端的新功能），Rust 编译器团队将确定他们是否认为这些新安全属性是对特定目标的尽力而为的改进，还是所有 Rust 目标的必要属性。在后一种情况下，编译器团队可能会要求现有目标的维护者实施并确认对该属性的支持，或者使用缺少属性的文档更新目标层级列表。
• 如果目标支持 C 代码，并且目标具有可互操作的 C 代码调用约定，则 Rust 目标必须通过 extern "C" 支持平台的 C 调用约定。但是，C 调用约定不需要成为目标的默认 Rust 调用约定。
• 目标必须在 CI 中可靠地构建，对于 Rust 的 CI 认为强制性的所有组件。
• 批准团队还可以要求 CI 中通过一部分测试，例如足以构建功能齐全的“hello world”程序、./x.py test --no-run 或等效的“冒烟测试”。特别是，如果目标构建宿主机工具，或者如果所讨论的测试通过早期检测关键问题提供实质性价值，则此要求可能适用。
• 在 CI 中构建目标的时间不得明显长于当前 CI 中最慢的目标，并且不应明显增加 CI 基础设施的维护负担。此要求是主观的，由基础设施团队评估，并将考虑目标的社区重要性。
• Tier 2 目标应尽可能支持交叉编译。Tier 2 目标不应要求使用目标作为构建宿主机，即使目标支持宿主机工具。
• 除了所有目标的法律要求（在 Tier 3 要求中指定）之外，由于 Tier 2 目标通常涉及 Rust 项目构建和提供各种编译后的二进制文件，因此合并目标并重新分发任何生成的编译后的二进制文件（例如，构建的库，如果有宿主机工具）不得对 Rust 项目的任何成员（包括基础设施团队成员和那些操作 CI 系统的人员）施加任何繁重的许可证要求。这是一个主观要求，由批准团队评估。
  • 作为对此的例外，如果目标的主要目的是为根据“著佐权”（要求根据兼容的 FOSS 条款许可其他代码的条款）条款许可的自由和开源软件 (FOSS) 项目（例如内核模块或插件）构建组件，则目标的标准库可能会受到著佐权条款的约束，只要 Rust 现有的提供完整对应源代码的做法满足这些条款即可。请注意，添加到 Rust 仓库本身的任何内容仍必须使用 Rust 的标准许可证条款。
• Tier 2 目标不得给 pull request 的作者或社区中的其他开发者带来确保目标测试通过的负担。特别是，不要在 PR 上发布评论（自动或手动），这些评论会因为目标测试失败而使 PR 偏离轨道或建议阻止 PR。除非 PR 作者或其他与 PR 相关的人员选择接收此类消息，否则不要向他们发送关于 PR 破坏 Tier 2 目标测试的自动消息或通知（通过任何媒介，包括通过 @）。
  • 当链接到 issue 或 PR 时，由 issue/PR 跟踪器生成的反向链接（例如那些）不被视为违反本策略，在合理的范围内。但是，此类消息（即使在单独的仓库中）也不得向任何未请求此类通知的 PR 相关人员生成通知。
• 目标维护者应定期为目标运行测试套件，并应及时修复任何测试失败。
• Tier 3 的所有要求均适用。

如果 Tier 2 目标不再满足这些要求，则可能会被降级或移除。任何降级或移除提案都将抄送给目标维护者，并在从稳定版本中删除之前广泛传达给 Rust 社区。（此类沟通与下一个稳定版本发布之间的时间间隔可能取决于失败要求的性质和严重程度、发现时间、目标是否已成为稳定版本的一部分以及降级或移除是否可以是计划和安排好的操作。）

在某些情况下，特别是如果目标维护者未及时响应，Rust 团队可能会提交 pull request，以暂时禁用夜间编译器中的某些目标，以便实现这些目标尚不支持的功能。（例如，这发生在引入 128 位类型 u128 和 i128 时。）此类 pull request 将包括通知并与此类目标的维护者协调，并且理想情况下会在新的开发周期的开始时进行，以便让维护者有时间更新其目标。然后，将期望此类目标的维护者实施相应的特定于目标的支持，以便重新启用目标。如果此类目标的维护者无法在下一个稳定版本发布之前及时提供此类支持，则可能会导致降级或移除目标。

Tier 2 与宿主机工具

一些 Tier 2 目标可能还具有构建为在其上作为宿主机运行的二进制文件（例如 rustc 和 cargo）。这允许将目标用作开发平台，而不仅仅是编译目标。

提议的带有宿主机工具的新 Tier 2 目标必须由编译器团队根据这些要求进行审查和批准。此类审查和批准可以通过重大变更提案 (MCP)进行。

此外，基础设施团队必须批准将目标的宿主机工具集成到持续集成 (CI) 中，以及宿主机工具的 CI 相关要求。此审查和批准可以在将目标的宿主机工具添加到 CI 的 PR 中进行，或者仅由基础设施团队成员报告团队讨论的结果。

• 根据目标、其功能、其性能以及任何给定工具的使用可能性，为 Tier 2 目标提供的宿主机工具可能仅包括 rustc 和 cargo，或者可能包括其他工具，例如 clippy 和 rustfmt。
• 宿主机工具的批准将考虑到构建宿主机工具所需的额外时间以及宿主机工具所需的巨大额外存储空间。
• 宿主机工具必须对除目标的维护者以外的人员具有直接价值。（它可能仍然是一个小众目标，但宿主机工具绝不能仅对一个本质上封闭的群体有用。）此要求将独立于相应的 Tier 2 要求进行评估。
  • 提供“直接价值”的要求意味着，仅仅争辩说拥有宿主机工具将帮助目标的维护者更轻松地向其他人提供目标是不够的。工具本身必须为其他人提供价值。
• 必须有合理的期望，即宿主机工具将被使用，用于除证明它们可以使用以外的目的。
• 宿主机工具必须在 CI 中可靠地构建和运行（对于 Rust 的 CI 认为强制性的所有组件），尽管它们可能通过或不通过测试。
• 为目标平台构建宿主工具所需时间不得明显长于为其他目标平台构建宿主工具的时间，并且不应大幅增加 CI 基础设施的维护负担。
• 宿主工具必须提供与在其他目标平台上实质上相似的体验，但受限于合理的目标平台限制。
  • 向现有工具添加实质上不同的接口，或向现有工具的功能添加特定于目标的接口，需要获得该工具相应审批团队的设计和实施批准（例如 RFC/MCP）。
    • 此类接口的设计应有可能适用于具有相似属性的其他目标平台。
    • 这应与目标平台的审查和批准分开进行，以简化目标平台的审查和批准流程，并简化对拟议新接口的审查和批准流程。
  • 例如，在沙箱中运行的目标平台可能需要修改文件处理、工具调用以及类似操作，以符合沙箱的预期和约定，但不允许引入与 CLI 接口分离的单独的“沙箱编译”接口，除非经过此类接口的正常审批流程。此类接口应考虑到可能具有类似沙箱的其他目标平台。
• 如果平台宿主工具通常应被签名或等效处理（例如，如果运行未签名的二进制文件或类似操作涉及“开发者模式”或额外的提示），则 Rust 项目的自动化构建必须能够应用适当的签名流程，而无需 Rust 开发者、目标平台维护者或第三方的任何手动干预。此流程必须获得基础设施团队的批准。
  • 此流程可能需要基础设施团队执行一次性或半定期的手动步骤，例如注册或续订签名密钥。任何此类手动流程都必须获得基础设施团队的批准。
  • 此流程可能需要与签名提供商签订法律协议。此类法律协议可能是可撤销的，并可能需要象征性的费用，但不应有其他繁重的义务。任何此类法律协议都必须获得基础设施团队的批准。（基础设施团队不期望或需要代表 Rust 项目签署具有约束力的法律协议；此审查和批准的存在是为了确保条款不繁重或给基础设施带来问题，特别是如果此类条款可能对有权访问特定于目标平台的基础设施的人员施加要求或义务。）
  • 对此流程或任何相关法律协议的更改可能会导致目标平台不再满足此要求。
  • 此流程必须在与公众大致相似的非繁重条款下提供。仅供 Rust 项目独家使用是不够的。
  • 此要求的存在是为了确保 Rust 构建，包括 nightly 构建，能够满足必要的条件，以允许用户顺利运行宿主工具。
• 提供宿主工具并不能免除目标平台在可能的情况下支持交叉编译的要求。
• Tier 2 的所有要求均适用。

如果目标平台满足所有必要的要求，则可以直接从 Tier 3 晋升到具有宿主工具的 Tier 2，但这样做可能会引入大量的额外复杂性。如有疑问，目标平台应首先获得不带宿主工具的 Tier 2 资格。

Tier 1 目标策略

在此层级，Rust 项目保证目标平台可以构建并通过所有测试，并将拒绝在目标平台上构建失败或未通过测试套件的补丁。我们对 Tier 1 目标平台的要求标准最高。

拟议的新 Tier 1 目标平台必须根据这些要求接受编译器团队的审查和批准。此外，发布团队必须批准支持该目标平台的可行性和价值。对于 Tier 1 目标平台，这通常将通过完整的 RFC 流程进行，该流程将由编译器团队和发布团队联合审查和批准。

此外，基础设施团队必须批准将目标平台集成到持续集成 (CI) 中，以及与 Tier 1 CI 相关的要求。此审查和批准可以通过将目标平台添加到 CI 的 PR 进行，也可以由基础设施团队成员报告团队讨论的结果，或者通过将基础设施团队纳入提议目标平台的 RFC 中进行。

• Tier 1 目标平台必须在开发者社区内具有广泛的、普遍的兴趣，并且必须满足多个组织或项目的多个生产用户的 Rust 持续需求。这些要求是主观的，由审批团队协商一致决定。如果 Tier 1 目标平台变得过时或不再满足此要求，则可能会被降级或移除。
• 目标平台维护团队必须至少包含 3 名开发者。
• 目标平台必须在 CI 中可靠地构建并通过测试，对于 Rust CI 认为强制执行的所有组件。
  • 为此，目标平台不得禁用测试套件中过多的测试或测试片段。这是一项主观要求。
  • 如果目标平台没有宿主工具支持，或者目标平台性能较低，则基础设施团队可以选择从另一个平台交叉编译测试套件，然后在本地或通过精确的模拟运行编译后的测试。但是，审批团队在确定目标平台或其宿主工具的可行性时，可能会考虑此类性能因素。
• 目标平台必须提供尽可能多的 Rust 标准库，并且应提供适当的标准库。例如，如果目标平台可以支持动态内存分配，则必须提供 alloc 及相关数据结构的实现。
• 构建目标平台和运行目标平台的测试套件所需时间不得明显长于其他目标平台，并且不应大幅增加 CI 基础设施的维护负担。
  • 特别是，如果构建目标平台花费的时间合理，但由于本地代码或精确模拟的性能较低，目标平台无法及时运行测试套件，则仅凭这一点就可能阻止目标平台获得 Tier 1 资格。
• 如果运行测试套件需要额外的基础设施（例如，运行目标平台的物理系统），则目标平台维护者必须安排向 Rust 项目提供此类资源，以满足 Rust 基础设施团队的满意和批准。
  • 此类资源可以通过云系统、模拟或物理硬件提供。
  • 如果目标平台需要使用模拟来满足任何层级要求，则这些要求的审批团队必须对模拟的准确性有高度信心，以便模拟和本地操作之间影响测试结果的差异将构成模拟或目标平台实现中的高优先级错误。
  • 如果无法通过模拟运行目标平台，则这些资源还必须足以让 Rust 基础设施团队能够让 Rust 团队成员访问，以进行开发和测试。（请注意，保持目标平台良好维护的特定于目标平台的开发责任仍然由目标平台维护者承担。此要求确保其他 Rust 开发者可以测试目标平台，但不强制其他 Rust 开发者进行特定于目标平台的修复。）
  • 为 CI 和类似基础设施提供的资源必须可供 Rust 项目持续独占使用。为 Rust 团队成员访问以进行开发和测试而提供的资源在使用时必须具有独占性，但在不使用时不必持续可用。
• Tier 1 目标平台不得对已签名、已验证或以其他方式“批准”的二进制文件有硬性要求。开发者必须能够在他们控制的系统上构建、运行和测试目标平台的二进制文件，或提供此类二进制文件供他人运行。（这样做可能需要在这些系统上启用某些适当的“开发者模式”，但不应要求支付任何额外费用或其他对价，或同意任何繁重的法律协议。）
  • 如果 Rust 项目认为提供适当签名的二进制文件可以为使用目标平台的开发者提供更流畅的体验，并且具有宿主工具的 Tier 2 目标平台已经需要提供适当的机制，使我们的基础设施能够提供此类签名的二进制文件，则 Rust 项目可能会决定提供适当签名的二进制文件。但是，此额外的 Tier 1 要求确保 Rust 开发者可以为目标平台开发和测试 Rust 软件（包括 Rust 本身），并且不会限制目标平台的开发或测试。
• Tier 2 的所有要求均适用。

如果 Tier 1 目标平台不再满足这些要求，但仍满足较低层级的要求，则可能会被降级。任何降级 Tier 1 目标平台的提议都需要完整的 RFC 流程，并获得编译器和发布团队的批准。任何此类提议都将在 Rust 社区中广泛沟通，无论是在最初提出时还是在从稳定版本中删除之前。Tier 1 目标平台极不可能在未先降级到 Tier 2 或 Tier 3 的情况下直接移除。（此类沟通与下一个稳定版本之间的时间间隔可能取决于失败要求的性质和严重程度、发现时间、目标平台是否已成为稳定版本的一部分，以及降级或移除是否可以是计划和安排的行动。）

提高 Tier 1 目标平台的基线期望（例如，所需的最低 CPU 功能或操作系统版本）需要获得编译器和发布团队的批准，并且也应广泛沟通，但并不一定需要完整的 RFC。

Tier 1 与宿主机工具

某些 Tier 1 目标平台可能还具有构建在其上作为宿主运行的二进制文件（例如 rustc 和 cargo）。这允许将目标平台用作开发平台，而不仅仅是编译目标。

拟议的具有宿主工具的新 Tier 1 目标平台必须根据这些要求接受编译器团队的审查和批准。此外，发布团队必须批准支持目标平台宿主工具的可行性和价值。对于 Tier 1 目标平台，这通常将通过完整的 RFC 流程进行，该流程将由编译器团队和发布团队联合审查和批准。

此外，基础设施团队必须批准将目标平台的宿主工具集成到持续集成 (CI) 中，以及与宿主工具相关的 CI 要求。此审查和批准可以通过将目标平台的宿主工具添加到 CI 的 PR 进行，也可以由基础设施团队成员报告团队讨论的结果，或者通过将基础设施团队纳入提议目标平台的 RFC 中进行。

• 具有宿主工具的 Tier 1 目标平台通常应包括所有额外的工具，例如 clippy 和 rustfmt，除非存在特定于目标平台的原因导致某个工具不可能适用于该目标平台。
  • 与 Tier 2 不同，对于 Tier 1，我们不会仅仅因为某些工具不太可能被使用而排除它们；相反，在考虑目标平台是否应该成为具有宿主工具的 Tier 1 时，我们会将此因素考虑在内。总的来说，在任何具有宿主工具的 Tier 1 目标平台上，人们应该能够期望找到并安装与任何其他具有宿主工具的 Tier 1 目标平台相同的组件。
• 宿主机工具的批准将考虑到构建宿主机工具所需的额外时间以及宿主机工具所需的巨大额外存储空间。
• 目标平台的宿主工具必须在开发者社区内具有广泛的、普遍的兴趣，并且必须满足多个组织或项目的多个生产用户的 Rust 持续需求。这些要求是主观的，由审批团队协商一致决定。此要求将独立于相应的 Tier 1 要求进行评估；目标平台可能对交叉编译具有足够的兴趣，但对本地编译可能没有足够的兴趣。如果宿主工具不再满足此要求，即使目标平台在其他方面符合 Tier 1 的资格，也可能会被删除。
• 目标平台的宿主工具必须在 CI 中可靠地构建、运行并通过测试，对于 Rust CI 认为强制执行的所有组件。
  • 为此，目标平台不得禁用测试套件中过多的测试或测试片段。这是一项主观要求。
• 构建宿主工具和运行宿主工具的测试套件所需时间不得明显长于其他目标平台，并且不应大幅增加 CI 基础设施的维护负担。
  • 特别是，如果构建目标平台的宿主工具花费的时间合理，但由于本地代码或精确模拟的性能较低，目标平台无法及时运行测试套件，则仅凭这一点就可能阻止目标平台获得具有宿主工具的 Tier 1 资格。
• 提供宿主工具并不能免除目标平台在可能的情况下支持交叉编译的要求。
• 具有宿主工具的 Tier 2 目标平台的所有要求均适用。
• Tier 1 的所有要求均适用。

寻求晋升到具有宿主工具的 Tier 1 的目标平台通常应已是具有宿主工具的 Tier 2 或不带宿主工具的 Tier 1，以减少需要同时审查和批准的要求数量。

除了降级 Tier 1 目标平台的一般流程外，如果具有宿主工具的 Tier 1 目标平台不再满足这些要求，但仍满足较低层级的要求，则可能会被降级（包括删除其宿主工具，或降级为具有宿主工具的 Tier 2）。任何降级 Tier 1 目标平台（无论是否具有宿主工具）的提议都需要完整的 RFC 流程，并获得编译器和发布团队的批准。任何此类提议都将在 Rust 社区中广泛沟通，无论是在最初提出时还是在从稳定版本中删除之前。