目标层级策略

目录

• 通用
• 添加新目标
• 第 3 层目标策略
• 第 2 层目标策略
  • 带有主机工具的第 2 层
• 第 1 层目标策略
  • 带有主机工具的第 1 层

通用

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

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

添加新的第 3 层目标只需要最少的条件；我们主要关注的是避免对其他正在进行的 Rust 开发造成干扰。

第 2 层和第 1 层目标将工作分配给整个 Rust 项目开发人员，以避免破坏目标。更广泛的 Rust 社区也可能更愿意在他们的板条箱中支持更高层级的目标（尽管他们没有义务这样做）。因此，这些层级要求目标维护人员付出相应的持续努力，以证明其价值并最大程度地减少对正在进行的 Rust 开发的任何干扰。

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

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

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

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

在提交引入或提升目标的问题或拉取请求 (PR) 之前，目标应已满足相应的层级要求。这并不排除现有目标的维护人员使用问题（在 Rust 存储库中或其他地方）来跟踪尚未满足的要求，视情况而定；但是，在正式提出引入或提升目标之前，它应满足所有必要的要求。目标提议必须逐字引用相应的要求，并作为解释目标如何满足这些要求的一部分进行响应。（对于简单地说明目标或目标开发人员不得做某事的要求，只需确认该要求即可。）

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

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

请注意，在提出晋升到下一层级的提议之前，目标必须已经获得下一层级的批准，并在该层级花费了合理的时间；即使目标一次满足多个层级的要求，也是如此。本策略将“合理时间”的准确解释留给批准团队；这些团队可能会根据他们对目标及其在当前层级所展示的跟踪记录的信心来调整所需的时间。至少，在目标晋升之间通常应出现多个稳定的 Rust 版本。

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

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

添加新目标

新目标通常从第 3 层开始，然后可以稍后晋升。要提出添加新目标，请在rust-lang/rust上打开一个拉取请求。

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

  r? compiler-team
  

第 3 层目标策略

在这个层级，Rust 项目不提供对目标的官方支持，因此我们对目标的引入提出了最少的条件。

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

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

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

如果第 3 层目标不再满足这些要求，或者目标维护者不再有兴趣或时间，或者目标没有显示出任何活动迹象并且已经有一段时间没有构建，或者删除目标会提高 Rust 代码库的质量，我们可能会发布一个 PR 来删除它；任何此类 PR 都会 CC 给目标维护者（以及可能以前在目标上工作过的其他人），以检查对改善这种情况的潜在兴趣。

第 2 层目标策略

在这个层级，Rust 项目保证目标会构建，并且会拒绝无法在目标上构建的补丁。因此，我们提出了确保目标不会阻碍 Rust 项目向前发展的要求。

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

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

• 第 2 层目标必须对除维护者以外的人员有价值。（它可能仍然是一个利基目标，但它不能仅对一个封闭的群体有用。）
• 第 2 层目标必须有一个指定的开发人员团队（“目标维护者”）可用于咨询目标特定的构建破坏问题，或者如果需要，开发目标特定的语言或库实现细节。该团队必须至少有 2 名开发人员。
  • 目标维护者不仅应该修复目标特定的问题，还应该利用任何此类问题作为机会教育 Rust 社区关于移植到他们的目标，并增强目标的文档。
• 目标不得给不专门关注该目标的 Rust 开发人员带来过大的负担。Rust 开发人员预计不会无缘无故地破坏第 2 层目标，但他们也不必成为每个第 2 层目标的专家，也不必为每个第 2 层目标提供目标特定的实现。
• 目标必须为 Rust 社区提供文档，说明如何使用交叉编译为目标构建，以及如何为目标运行测试。如果可能，此文档应显示如何使用仿真为目标运行 Rust 程序和测试，以允许任何人这样做。如果目标无法可行地仿真，则文档应说明如何获取和使用物理硬件、云系统或等效系统。
• 目标必须记录其对 CPU、操作系统、库、运行时环境等的特性或版本的基线预期。
• 如果引入一个新的第 2 层或更高层目标，该目标与现有的 Rust 目标相同，只是对 CPU、操作系统、库、运行时环境等的特性或版本的基线预期不同，那么提议的目标必须记录以使批准团队满意，为什么基线预期的具体差异提供了足够的价值来证明一个单独的目标。
  • 请注意，在某些情况下，根据 Rust 社区中现有目标的使用情况，Rust 开发人员或目标的维护者可能希望修改目标的基线预期，或将现有目标拆分为具有不同基线预期的多个目标。对此进行的提案将与类似的提升、降级或删除目标的处理方式类似，根据本政策，需要相同的团队批准。
    • 例如，如果某个操作系统版本已过时且不受支持，则针对该操作系统的目标可能会提高其对操作系统版本的基线预期（视为删除对应于旧版本的目标），或者针对该操作系统的目标可能会将对旧操作系统版本的支持拆分为一个较低层级的目标（视为将对应于旧版本的目标降级，并需要为旧操作系统版本的较低层级目标提供理由）。
• 第 2 层目标不得留下任何重要的 core 或标准库部分未实现或存根，除非它们不可能在目标上得到支持。
  • 处理目标中缺少功能的正确方法可能取决于目标是否可能在将来开发该功能。在某些情况下，目标可能会与 Rust 支持一起开发，并且 Rust 可能会随着目标获得支持这些功能的能力而获得目标上的新功能。
  • 作为例外，与现有第 1 层目标相同，只是对操作系统、CPU 或类似的基线预期较低的目标，可以提议在没有 std 支持的情况下，作为第 2 层（但不是更高层）进行资格认证，如果目标主要用于 no_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 基础设施的维护负担。此要求是主观的，由基础设施团队评估，并将考虑目标的社区重要性。
• 如果可能，2 级目标应支持交叉编译。2 级目标不应要求使用目标作为构建的主机，即使目标支持主机工具。
• 除了所有目标的法律要求（在 3 级要求中指定）之外，因为 2 级目标通常涉及 Rust 项目构建和提供各种编译后的二进制文件，所以合并目标并重新分发任何生成的编译后的二进制文件（例如，构建的库，主机工具（如果有））不得对 Rust 项目的任何成员（包括基础设施团队成员和操作 CI 系统的人员）施加任何繁重的许可要求。这是一个主观要求，由批准团队评估。
  • 作为例外，如果目标的主要目的是为根据“复制左”条款（要求根据兼容的 FOSS 条款许可其他代码的条款）许可的自由和开源软件 (FOSS) 项目构建组件，例如内核模块或插件，那么目标的标准库可能受复制左条款的约束，只要这些条款得到 Rust 提供完整对应源代码的现有做法的满足。请注意，添加到 Rust 存储库本身的任何内容仍然必须使用 Rust 的标准许可条款。
• 2 级目标不得给拉取请求的作者或社区中的其他开发人员带来负担，以确保测试通过目标。特别是，不要在 PR 上发布（自动或手动）评论，这些评论会基于目标测试失败而使 PR 脱轨或建议阻止 PR。不要向 PR 作者或参与 PR 的其他人发送自动消息或通知（通过任何媒介，包括通过 @），告知 PR 在 2 级目标上破坏了测试，除非他们选择接收此类消息。
  • 在合理范围内，问题/PR 跟踪器在链接到问题或 PR 时生成的回链不被视为违反本政策。但是，此类消息（即使在单独的存储库中）不得向任何参与 PR 但未请求此类通知的人员生成通知。
• 目标维护者应定期运行目标的测试套件，并应在合理的时间内修复任何测试失败。
• 3 级的所有要求都适用。

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

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

带有主机工具的第 2 层

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

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

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

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

如果目标满足所有必要的要求，则可以将其直接从 3 级提升到具有主机工具的 2 级，但这样做可能会引入大量的额外复杂性。如有疑问，目标应首先在没有主机工具的情况下获得 2 级资格。

第 1 层目标策略

在此层级，Rust 项目保证目标构建并通过所有测试，并将拒绝无法构建或无法通过目标测试套件的补丁。我们对 1 级目标采用最高标准的要求。

提议的新 1 级目标必须根据这些要求由编译器团队审查和批准。此外，发布团队必须批准支持目标的可行性和价值。对于 1 级目标，这通常将通过完整的 RFC 提议目标来进行，该 RFC 将由编译器团队和发布团队共同审查和批准。

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

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

如果一级目标平台不再满足这些要求，但仍满足较低级别的要求，则可以将其降级。任何降级一级目标平台的提案都需要完整的 RFC 流程，并获得编译器和发布团队的批准。任何此类提案都将在最初提出时以及在从稳定版本中删除之前广泛传播给 Rust 社区。一级目标平台极不可能在没有先降级为二级或三级的情况下直接删除。（这种传播和下一个稳定版本之间的间隔时间可能取决于失败要求的性质和严重程度、发现的时间、目标平台是否已成为稳定版本的一部分以及降级或删除是否可以是计划和安排的操作。）

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

带有主机工具的第 1 层

一些一级目标平台可能还会构建二进制文件以在它们上作为主机运行（例如 rustc 和 cargo）。这允许目标平台用作开发平台，而不仅仅是编译目标。

具有主机工具的拟议新一级目标平台必须由编译器团队根据这些要求进行审查和批准。此外，发布团队必须批准支持目标平台主机工具的可行性和价值。对于一级目标平台，这通常会通过完整的 RFC 来完成，该 RFC 提出目标平台，由编译器团队和发布团队共同审查和批准。

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

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

寻求晋升为带有主机工具的一级目标平台通常应该要么是带有主机工具的二级目标平台，要么是无主机工具的一级目标平台，以减少同时审查和批准的要求数量。

除了降级一级目标的一般流程外，如果一级目标不再满足这些要求，但仍然满足较低级别的要求，则可以降级一级目标（包括删除其主机工具，或降级为二级目标并保留主机工具）。任何降级一级目标（无论是否带有主机工具）的提案都需要完整的 RFC 流程，并获得编译器和发布团队的批准。任何此类提案将在最初提出时以及在从稳定版本中删除之前，广泛传播给 Rust 社区。