]>
Commit | Line | Data |
---|---|---|
cdc7bbd5 XL |
1 | # Target Tier Policy |
2 | ||
17df50a5 XL |
3 | ## Table of Contents |
4 | ||
5 | * [General](#general) | |
487cf647 | 6 | * [Adding a new target](#adding-a-new-target) |
17df50a5 XL |
7 | * [Tier 3 target policy](#tier-3-target-policy) |
8 | * [Tier 2 target policy](#tier-2-target-policy) | |
9 | * [Tier 2 with host tools](#tier-2-with-host-tools) | |
10 | * [Tier 1 target policy](#tier-1-target-policy) | |
11 | * [Tier 1 with host tools](#tier-1-with-host-tools) | |
12 | ||
13 | ## General | |
14 | ||
cdc7bbd5 XL |
15 | Rust provides three tiers of target support: |
16 | ||
17 | - Rust provides no guarantees about tier 3 targets; they exist in the codebase, | |
18 | but may or may not build. | |
19 | - Rust's continuous integration checks that tier 2 targets will always build, | |
20 | but they may or may not pass tests. | |
21 | - Rust's continuous integration checks that tier 1 targets will always build | |
22 | and pass tests. | |
23 | ||
24 | Adding a new tier 3 target imposes minimal requirements; we focus primarily on | |
25 | avoiding disruption to other ongoing Rust development. | |
26 | ||
27 | Tier 2 and tier 1 targets place work on Rust project developers as a whole, to | |
28 | avoid breaking the target. The broader Rust community may also feel more | |
29 | inclined to support higher-tier targets in their crates (though they are not | |
30 | obligated to do so). Thus, these tiers require commensurate and ongoing efforts | |
31 | from the maintainers of the target, to demonstrate value and to minimize any | |
32 | disruptions to ongoing Rust development. | |
33 | ||
34 | This policy defines the requirements for accepting a proposed target at a given | |
35 | level of support. | |
36 | ||
37 | Each tier builds on all the requirements from the previous tier, unless | |
38 | overridden by a stronger requirement. Targets at tier 2 and tier 1 may also | |
39 | provide *host tools* (such as `rustc` and `cargo`); each of those tiers | |
40 | includes a set of supplementary requirements that must be met if supplying host | |
41 | tools for the target. A target at tier 2 or tier 1 is not required to supply | |
42 | host tools, but if it does, it must meet the corresponding additional | |
43 | requirements for host tools. | |
44 | ||
45 | The policy for each tier also documents the Rust governance teams that must | |
46 | approve the addition of any target at that tier. Those teams are responsible | |
47 | for reviewing and evaluating the target, based on these requirements and their | |
48 | own judgment. Those teams may apply additional requirements, including | |
49 | subjective requirements, such as to deal with issues not foreseen by this | |
50 | policy. (Such requirements may subsequently motivate additions to this policy.) | |
51 | ||
52 | While these criteria attempt to document the policy, that policy still involves | |
53 | human judgment. Targets must fulfill the spirit of the requirements as well, as | |
54 | determined by the judgment of the approving teams. Reviewers and team members | |
55 | evaluating targets and target-specific patches should always use their own best | |
56 | judgment regarding the quality of work, and the suitability of a target for the | |
57 | Rust project. Neither this policy nor any decisions made regarding targets | |
58 | shall create any binding agreement or estoppel by any party. | |
59 | ||
60 | Before filing an issue or pull request (PR) to introduce or promote a target, | |
61 | the target should already meet the corresponding tier requirements. This does | |
62 | not preclude an existing target's maintainers using issues (on the Rust | |
63 | repository or otherwise) to track requirements that have not yet been met, as | |
64 | appropriate; however, before officially proposing the introduction or promotion | |
65 | of a target, it should meet all of the necessary requirements. A target | |
5099ac24 FG |
66 | proposal must quote the corresponding requirements verbatim and respond to them |
67 | as part of explaining how the target meets those requirements. (For the | |
68 | requirements that simply state that the target or the target developers must | |
69 | not do something, it suffices to acknowledge the requirement.) | |
cdc7bbd5 XL |
70 | |
71 | For a list of all supported targets and their corresponding tiers ("tier 3", | |
72 | "tier 2", "tier 2 with host tools", "tier 1", or "tier 1 with host tools"), see | |
73 | [platform support](platform-support.md). | |
74 | ||
5099ac24 FG |
75 | Several parts of this policy require providing target-specific documentation. |
76 | Such documentation should typically appear in a subdirectory of the | |
77 | platform-support section of this rustc manual, with a link from the target's | |
78 | entry in [platform support](platform-support.md). Use | |
79 | [TEMPLATE.md](platform-support/TEMPLATE.md) as a base, and see other | |
80 | documentation in that directory for examples. | |
81 | ||
cdc7bbd5 XL |
82 | Note that a target must have already received approval for the next lower tier, |
83 | and spent a reasonable amount of time at that tier, before making a proposal | |
84 | for promotion to the next higher tier; this is true even if a target meets the | |
85 | requirements for several tiers at once. This policy leaves the precise | |
86 | interpretation of "reasonable amount of time" up to the approving teams; those | |
87 | teams may scale the amount of time required based on their confidence in the | |
88 | target and its demonstrated track record at its current tier. At a minimum, | |
89 | multiple stable releases of Rust should typically occur between promotions of a | |
90 | target. | |
91 | ||
92 | The availability or tier of a target in stable Rust is not a hard stability | |
93 | guarantee about the future availability or tier of that target. Higher-level | |
94 | target tiers are an increasing commitment to the support of a target, and we | |
95 | will take that commitment and potential disruptions into account when | |
96 | evaluating the potential demotion or removal of a target that has been part of | |
97 | a stable release. The promotion or demotion of a target will not generally | |
98 | affect existing stable releases, only current development and future releases. | |
99 | ||
100 | In this policy, the words "must" and "must not" specify absolute requirements | |
101 | that a target must meet to qualify for a tier. The words "should" and "should | |
102 | not" specify requirements that apply in almost all cases, but for which the | |
103 | approving teams may grant an exception for good reason. The word "may" | |
104 | indicates something entirely optional, and does not indicate guidance or | |
105 | recommendations. This language is based on [IETF RFC | |
106 | 2119](https://tools.ietf.org/html/rfc2119). | |
107 | ||
487cf647 FG |
108 | ## Adding a new target |
109 | ||
110 | New targets typically start as Tier 3 and then can be promoted later. | |
111 | To propose addition of a new target, open a pull request on [`rust-lang/rust`]: | |
112 | ||
113 | - Copy the [Tier 3 target policy](#tier-3-target-policy) to the description | |
114 | and fill it out, see [example][tier3example]. | |
115 | - Add a new description for the target in `src/doc/rustc/src/platform-support` | |
116 | using the [template][platform_template]. | |
117 | - Add the target to the [SUMMARY.md][summary] (allows wildcards) and | |
118 | [platform-support.md][platformsupport] (must name all targets verbatim). | |
119 | Link to the created description page. | |
120 | - Ensure the pull request is assigned to a member of the [Rust compiler team][rust_compiler_team] by commenting: | |
121 | ```text | |
122 | r? compiler-team | |
123 | ``` | |
124 | ||
125 | [tier3example]: https://github.com/rust-lang/rust/pull/94872 | |
126 | [platform_template]: https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support/TEMPLATE.md | |
127 | [summary]: https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/SUMMARY.md | |
128 | [platformsupport]: https://github.com/rust-lang/rust/blob/master/src/doc/rustc/src/platform-support.md | |
129 | [rust_compiler_team]: https://www.rust-lang.org/governance/teams/compiler | |
130 | [`rust-lang/rust`]: https://github.com/rust-lang/rust | |
131 | ||
cdc7bbd5 XL |
132 | ## Tier 3 target policy |
133 | ||
134 | At this tier, the Rust project provides no official support for a target, so we | |
135 | place minimal requirements on the introduction of targets. | |
136 | ||
137 | A proposed new tier 3 target must be reviewed and approved by a member of the | |
138 | compiler team based on these requirements. The reviewer may choose to gauge | |
17df50a5 | 139 | broader compiler team consensus via a [Major Change Proposal (MCP)][MCP]. |
cdc7bbd5 XL |
140 | |
141 | A proposed target or target-specific patch that substantially changes code | |
142 | shared with other targets (not just target-specific code) must be reviewed and | |
143 | approved by the appropriate team for that shared code before acceptance. | |
144 | ||
145 | - A tier 3 target must have a designated developer or developers (the "target | |
146 | maintainers") on record to be CCed when issues arise regarding the target. | |
147 | (The mechanism to track and CC such developers may evolve over time.) | |
148 | - Targets must use naming consistent with any existing targets; for instance, a | |
149 | target for the same CPU or OS as an existing Rust target should use the same | |
150 | name for that CPU or OS. Targets should normally use the same names and | |
151 | naming conventions as used elsewhere in the broader ecosystem beyond Rust | |
152 | (such as in other toolchains), unless they have a very good reason to | |
153 | diverge. Changing the name of a target can be highly disruptive, especially | |
154 | once the target reaches a higher tier, so getting the name right is important | |
155 | even for a tier 3 target. | |
156 | - Target names should not introduce undue confusion or ambiguity unless | |
157 | absolutely necessary to maintain ecosystem compatibility. For example, if | |
158 | the name of the target makes people extremely likely to form incorrect | |
159 | beliefs about what it targets, the name should be changed or augmented to | |
160 | disambiguate it. | |
487cf647 FG |
161 | - If possible, use only letters, numbers, dashes and underscores for the name. |
162 | Periods (`.`) are known to cause issues in Cargo. | |
cdc7bbd5 XL |
163 | - Tier 3 targets may have unusual requirements to build or use, but must not |
164 | create legal issues or impose onerous legal terms for the Rust project or for | |
165 | Rust developers or users. | |
166 | - The target must not introduce license incompatibilities. | |
167 | - Anything added to the Rust repository must be under the standard Rust | |
168 | license (`MIT OR Apache-2.0`). | |
169 | - The target must not cause the Rust tools or libraries built for any other | |
170 | host (even when supporting cross-compilation to the target) to depend | |
171 | on any new dependency less permissive than the Rust licensing policy. This | |
172 | applies whether the dependency is a Rust crate that would require adding | |
173 | new license exceptions (as specified by the `tidy` tool in the | |
174 | rust-lang/rust repository), or whether the dependency is a native library | |
175 | or binary. In other words, the introduction of the target must not cause a | |
176 | user installing or running a version of Rust or the Rust tools to be | |
177 | subject to any new license requirements. | |
5099ac24 FG |
178 | - Compiling, linking, and emitting functional binaries, libraries, or other |
179 | code for the target (whether hosted on the target itself or cross-compiling | |
180 | from another target) must not depend on proprietary (non-FOSS) libraries. | |
181 | Host tools built for the target itself may depend on the ordinary runtime | |
182 | libraries supplied by the platform and commonly used by other applications | |
183 | built for the target, but those libraries must not be required for code | |
184 | generation for the target; cross-compilation to the target must not require | |
185 | such libraries at all. For instance, `rustc` built for the target may | |
186 | depend on a common proprietary C runtime library or console output library, | |
187 | but must not depend on a proprietary code generation library or code | |
188 | optimization library. Rust's license permits such combinations, but the | |
189 | Rust project has no interest in maintaining such combinations within the | |
190 | scope of Rust itself, even at tier 3. | |
cdc7bbd5 XL |
191 | - "onerous" here is an intentionally subjective term. At a minimum, "onerous" |
192 | legal/licensing terms include but are *not* limited to: non-disclosure | |
193 | requirements, non-compete requirements, contributor license agreements | |
194 | (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, | |
195 | requirements conditional on the employer or employment of any particular | |
196 | Rust developers, revocable terms, any requirements that create liability | |
197 | for the Rust project or its developers or users, or any requirements that | |
198 | adversely affect the livelihood or prospects of the Rust project or its | |
199 | developers or users. | |
200 | - Neither this policy nor any decisions made regarding targets shall create any | |
201 | binding agreement or estoppel by any party. If any member of an approving | |
202 | Rust team serves as one of the maintainers of a target, or has any legal or | |
203 | employment requirement (explicit or implicit) that might affect their | |
204 | decisions regarding a target, they must recuse themselves from any approval | |
205 | decisions regarding the target's tier status, though they may otherwise | |
206 | participate in discussions. | |
207 | - This requirement does not prevent part or all of this policy from being | |
208 | cited in an explicit contract or work agreement (e.g. to implement or | |
209 | maintain support for a target). This requirement exists to ensure that a | |
210 | developer or team responsible for reviewing and approving a target does not | |
211 | face any legal threats or obligations that would prevent them from freely | |
212 | exercising their judgment in such approval, even if such judgment involves | |
213 | subjective matters or goes beyond the letter of these requirements. | |
214 | - Tier 3 targets should attempt to implement as much of the standard libraries | |
215 | as possible and appropriate (`core` for most targets, `alloc` for targets | |
216 | that can support dynamic memory allocation, `std` for targets with an | |
217 | operating system or equivalent layer of system-provided functionality), but | |
218 | may leave some code unimplemented (either unavailable or stubbed out as | |
219 | appropriate), whether because the target makes it impossible to implement or | |
220 | challenging to implement. The authors of pull requests are not obligated to | |
221 | avoid calling any portions of the standard library on the basis of a tier 3 | |
222 | target not implementing those portions. | |
223 | - The target must provide documentation for the Rust community explaining how | |
224 | to build for the target, using cross-compilation if possible. If the target | |
5099ac24 FG |
225 | supports running binaries, or running tests (even if they do not pass), the |
226 | documentation must explain how to run such binaries or tests for the target, | |
227 | using emulation if possible or dedicated hardware if necessary. | |
cdc7bbd5 XL |
228 | - Tier 3 targets must not impose burden on the authors of pull requests, or |
229 | other developers in the community, to maintain the target. In particular, | |
230 | do not post comments (automated or manual) on a PR that derail or suggest a | |
231 | block on the PR based on a tier 3 target. Do not send automated messages or | |
232 | notifications (via any medium, including via `@`) to a PR author or others | |
233 | involved with a PR regarding a tier 3 target, unless they have opted into | |
234 | such messages. | |
235 | - Backlinks such as those generated by the issue/PR tracker when linking to | |
236 | an issue or PR are not considered a violation of this policy, within | |
237 | reason. However, such messages (even on a separate repository) must not | |
238 | generate notifications to anyone involved with a PR who has not requested | |
239 | such notifications. | |
240 | - Patches adding or updating tier 3 targets must not break any existing tier 2 | |
241 | or tier 1 target, and must not knowingly break another tier 3 target without | |
242 | approval of either the compiler team or the maintainers of the other tier 3 | |
243 | target. | |
244 | - In particular, this may come up when working on closely related targets, | |
245 | such as variations of the same architecture with different features. Avoid | |
246 | introducing unconditional uses of features that another variation of the | |
247 | target may not have; use conditional compilation or runtime detection, as | |
248 | appropriate, to let each target run code supported by that target. | |
249 | ||
250 | If a tier 3 target stops meeting these requirements, or the target maintainers | |
251 | no longer have interest or time, or the target shows no signs of activity and | |
252 | has not built for some time, or removing the target would improve the quality | |
253 | of the Rust codebase, we may post a PR to remove it; any such PR will be CCed | |
254 | to the target maintainers (and potentially other people who have previously | |
255 | worked on the target), to check potential interest in improving the situation. | |
256 | ||
257 | ## Tier 2 target policy | |
258 | ||
259 | At this tier, the Rust project guarantees that a target builds, and will reject | |
260 | patches that fail to build on a target. Thus, we place requirements that ensure | |
261 | the target will not block forward progress of the Rust project. | |
262 | ||
263 | A proposed new tier 2 target must be reviewed and approved by the compiler team | |
17df50a5 XL |
264 | based on these requirements. Such review and approval may occur via a [Major |
265 | Change Proposal (MCP)][MCP]. | |
cdc7bbd5 XL |
266 | |
267 | In addition, the infrastructure team must approve the integration of the target | |
268 | into Continuous Integration (CI), and the tier 2 CI-related requirements. This | |
269 | review and approval may take place in a PR adding the target to CI, or simply | |
270 | by an infrastructure team member reporting the outcome of a team discussion. | |
271 | ||
272 | - A tier 2 target must have value to people other than its maintainers. (It may | |
273 | still be a niche target, but it must not be exclusively useful for an | |
274 | inherently closed group.) | |
275 | - A tier 2 target must have a designated team of developers (the "target | |
276 | maintainers") available to consult on target-specific build-breaking issues, | |
277 | or if necessary to develop target-specific language or library implementation | |
278 | details. This team must have at least 2 developers. | |
279 | - The target maintainers should not only fix target-specific issues, but | |
280 | should use any such issue as an opportunity to educate the Rust community | |
281 | about portability to their target, and enhance documentation of the target. | |
282 | - The target must not place undue burden on Rust developers not specifically | |
283 | concerned with that target. Rust developers are expected to not gratuitously | |
284 | break a tier 2 target, but are not expected to become experts in every tier 2 | |
285 | target, and are not expected to provide target-specific implementations for | |
286 | every tier 2 target. | |
287 | - The target must provide documentation for the Rust community explaining how | |
288 | to build for the target using cross-compilation, and explaining how to run | |
289 | tests for the target. If at all possible, this documentation should show how | |
290 | to run Rust programs and tests for the target using emulation, to allow | |
291 | anyone to do so. If the target cannot be feasibly emulated, the documentation | |
292 | should explain how to obtain and work with physical hardware, cloud systems, | |
293 | or equivalent. | |
294 | - The target must document its baseline expectations for the features or | |
295 | versions of CPUs, operating systems, libraries, runtime environments, and | |
296 | similar. | |
297 | - If introducing a new tier 2 or higher target that is identical to an existing | |
298 | Rust target except for the baseline expectations for the features or versions | |
299 | of CPUs, operating systems, libraries, runtime environments, and similar, | |
300 | then the proposed target must document to the satisfaction of the approving | |
301 | teams why the specific difference in baseline expectations provides | |
302 | sufficient value to justify a separate target. | |
303 | - Note that in some cases, based on the usage of existing targets within the | |
304 | Rust community, Rust developers or a target's maintainers may wish to | |
305 | modify the baseline expectations of a target, or split an existing target | |
306 | into multiple targets with different baseline expectations. A proposal to | |
307 | do so will be treated similarly to the analogous promotion, demotion, or | |
308 | removal of a target, according to this policy, with the same team approvals | |
309 | required. | |
310 | - For instance, if an OS version has become obsolete and unsupported, a | |
311 | target for that OS may raise its baseline expectations for OS version | |
312 | (treated as though removing a target corresponding to the older | |
313 | versions), or a target for that OS may split out support for older OS | |
314 | versions into a lower-tier target (treated as though demoting a target | |
315 | corresponding to the older versions, and requiring justification for a | |
316 | new target at a lower tier for the older OS versions). | |
317 | - Tier 2 targets must not leave any significant portions of `core` or the | |
318 | standard library unimplemented or stubbed out, unless they cannot possibly be | |
319 | supported on the target. | |
320 | - The right approach to handling a missing feature from a target may depend | |
321 | on whether the target seems likely to develop the feature in the future. In | |
322 | some cases, a target may be co-developed along with Rust support, and Rust | |
323 | may gain new features on the target as that target gains the capabilities | |
324 | to support those features. | |
325 | - As an exception, a target identical to an existing tier 1 target except for | |
326 | lower baseline expectations for the OS, CPU, or similar, may propose to | |
327 | qualify as tier 2 (but not higher) without support for `std` if the target | |
328 | will primarily be used in `no_std` applications, to reduce the support | |
329 | burden for the standard library. In this case, evaluation of the proposed | |
330 | target's value will take this limitation into account. | |
331 | - The code generation backend for the target should not have deficiencies that | |
332 | invalidate Rust safety properties, as evaluated by the Rust compiler team. | |
333 | (This requirement does not apply to arbitrary security enhancements or | |
334 | mitigations provided by code generation backends, only to those properties | |
335 | needed to ensure safe Rust code cannot cause undefined behavior or other | |
336 | unsoundness.) If this requirement does not hold, the target must clearly and | |
337 | prominently document any such limitations as part of the target's entry in | |
338 | the target tier list, and ideally also via a failing test in the testsuite. | |
339 | The Rust compiler team must be satisfied with the balance between these | |
340 | limitations and the difficulty of implementing the necessary features. | |
341 | - For example, if Rust relies on a specific code generation feature to ensure | |
342 | that safe code cannot overflow the stack, the code generation for the | |
343 | target should support that feature. | |
344 | - If the Rust compiler introduces new safety properties (such as via new | |
345 | capabilities of a compiler backend), the Rust compiler team will determine | |
346 | if they consider those new safety properties a best-effort improvement for | |
347 | specific targets, or a required property for all Rust targets. In the | |
348 | latter case, the compiler team may require the maintainers of existing | |
349 | targets to either implement and confirm support for the property or update | |
350 | the target tier list with documentation of the missing property. | |
351 | - If the target supports C code, and the target has an interoperable calling | |
352 | convention for C code, the Rust target must support that C calling convention | |
353 | for the platform via `extern "C"`. The C calling convention does not need to | |
354 | be the default Rust calling convention for the target, however. | |
355 | - The target must build reliably in CI, for all components that Rust's CI | |
356 | considers mandatory. | |
357 | - The approving teams may additionally require that a subset of tests pass in | |
358 | CI, such as enough to build a functional "hello world" program, `./x.py test | |
359 | --no-run`, or equivalent "smoke tests". In particular, this requirement may | |
360 | apply if the target builds host tools, or if the tests in question provide | |
361 | substantial value via early detection of critical problems. | |
362 | - Building the target in CI must not take substantially longer than the current | |
363 | slowest target in CI, and should not substantially raise the maintenance | |
364 | burden of the CI infrastructure. This requirement is subjective, to be | |
365 | evaluated by the infrastructure team, and will take the community importance | |
366 | of the target into account. | |
367 | - Tier 2 targets should, if at all possible, support cross-compiling. Tier 2 | |
368 | targets should not require using the target as the host for builds, even if | |
369 | the target supports host tools. | |
370 | - In addition to the legal requirements for all targets (specified in the tier | |
371 | 3 requirements), because a tier 2 target typically involves the Rust project | |
372 | building and supplying various compiled binaries, incorporating the target | |
373 | and redistributing any resulting compiled binaries (e.g. built libraries, | |
374 | host tools if any) must not impose any onerous license requirements on any | |
375 | members of the Rust project, including infrastructure team members and those | |
376 | operating CI systems. This is a subjective requirement, to be evaluated by | |
377 | the approving teams. | |
378 | - As an exception to this, if the target's primary purpose is to build | |
379 | components for a Free and Open Source Software (FOSS) project licensed | |
380 | under "copyleft" terms (terms which require licensing other code under | |
381 | compatible FOSS terms), such as kernel modules or plugins, then the | |
382 | standard libraries for the target may potentially be subject to copyleft | |
383 | terms, as long as such terms are satisfied by Rust's existing practices of | |
384 | providing full corresponding source code. Note that anything added to the | |
385 | Rust repository itself must still use Rust's standard license terms. | |
386 | - Tier 2 targets must not impose burden on the authors of pull requests, or | |
387 | other developers in the community, to ensure that tests pass for the target. | |
388 | In particular, do not post comments (automated or manual) on a PR that derail | |
389 | or suggest a block on the PR based on tests failing for the target. Do not | |
390 | send automated messages or notifications (via any medium, including via `@`) | |
391 | to a PR author or others involved with a PR regarding the PR breaking tests | |
392 | on a tier 2 target, unless they have opted into such messages. | |
393 | - Backlinks such as those generated by the issue/PR tracker when linking to | |
394 | an issue or PR are not considered a violation of this policy, within | |
395 | reason. However, such messages (even on a separate repository) must not | |
396 | generate notifications to anyone involved with a PR who has not requested | |
397 | such notifications. | |
398 | - The target maintainers should regularly run the testsuite for the target, and | |
399 | should fix any test failures in a reasonably timely fashion. | |
400 | - All requirements for tier 3 apply. | |
401 | ||
402 | A tier 2 target may be demoted or removed if it no longer meets these | |
403 | requirements. Any proposal for demotion or removal will be CCed to the target | |
404 | maintainers, and will be communicated widely to the Rust community before being | |
405 | dropped from a stable release. (The amount of time between such communication | |
406 | and the next stable release may depend on the nature and severity of the failed | |
407 | requirement, the timing of its discovery, whether the target has been part of a | |
408 | stable release yet, and whether the demotion or removal can be a planned and | |
409 | scheduled action.) | |
410 | ||
411 | In some circumstances, especially if the target maintainers do not respond in a | |
412 | timely fashion, Rust teams may land pull requests that temporarily disable some | |
413 | targets in the nightly compiler, in order to implement a feature not yet | |
414 | supported by those targets. (As an example, this happened when introducing the | |
415 | 128-bit types `u128` and `i128`.) Such a pull request will include notification | |
416 | and coordination with the maintainers of such targets, and will ideally happen | |
417 | towards the beginning of a new development cycle to give maintainers time to | |
418 | update their targets. The maintainers of such targets will then be expected to | |
419 | implement the corresponding target-specific support in order to re-enable the | |
420 | target. If the maintainers of such targets cannot provide such support in time | |
421 | for the next stable release, this may result in demoting or removing the | |
422 | targets. | |
423 | ||
424 | ### Tier 2 with host tools | |
425 | ||
426 | Some tier 2 targets may additionally have binaries built to run on them as a | |
427 | host (such as `rustc` and `cargo`). This allows the target to be used as a | |
428 | development platform, not just a compilation target. | |
429 | ||
430 | A proposed new tier 2 target with host tools must be reviewed and approved by | |
431 | the compiler team based on these requirements. Such review and approval may | |
17df50a5 | 432 | occur via a [Major Change Proposal (MCP)][MCP]. |
cdc7bbd5 XL |
433 | |
434 | In addition, the infrastructure team must approve the integration of the | |
435 | target's host tools into Continuous Integration (CI), and the CI-related | |
436 | requirements for host tools. This review and approval may take place in a PR | |
437 | adding the target's host tools to CI, or simply by an infrastructure team | |
438 | member reporting the outcome of a team discussion. | |
439 | ||
440 | - Depending on the target, its capabilities, its performance, and the | |
441 | likelihood of use for any given tool, the host tools provided for a tier 2 | |
442 | target may include only `rustc` and `cargo`, or may include additional tools | |
443 | such as `clippy` and `rustfmt`. | |
444 | - Approval of host tools will take into account the additional time required to | |
445 | build the host tools, and the substantial additional storage required for the | |
446 | host tools. | |
447 | - The host tools must have direct value to people other than the target's | |
448 | maintainers. (It may still be a niche target, but the host tools must not be | |
449 | exclusively useful for an inherently closed group.) This requirement will be | |
450 | evaluated independently from the corresponding tier 2 requirement. | |
451 | - The requirement to provide "direct value" means that it does not suffice to | |
452 | argue that having host tools will help the target's maintainers more easily | |
453 | provide the target to others. The tools themselves must provide value to | |
454 | others. | |
455 | - There must be a reasonable expectation that the host tools will be used, for | |
456 | purposes other than to prove that they can be used. | |
457 | - The host tools must build and run reliably in CI (for all components that | |
458 | Rust's CI considers mandatory), though they may or may not pass tests. | |
459 | - Building host tools for the target must not take substantially longer than | |
460 | building host tools for other targets, and should not substantially raise the | |
461 | maintenance burden of the CI infrastructure. | |
462 | - The host tools must provide a substantively similar experience as on other | |
463 | targets, subject to reasonable target limitations. | |
464 | - Adding a substantively different interface to an existing tool, or a | |
465 | target-specific interface to the functionality of an existing tool, | |
466 | requires design and implementation approval (e.g. RFC/MCP) from the | |
467 | appropriate approving teams for that tool. | |
468 | - Such an interface should have a design that could potentially work for | |
469 | other targets with similar properties. | |
470 | - This should happen separately from the review and approval of the target, | |
471 | to simplify the target review and approval processes, and to simplify the | |
472 | review and approval processes for the proposed new interface. | |
473 | - By way of example, a target that runs within a sandbox may need to modify | |
474 | the handling of files, tool invocation, and similar to meet the | |
475 | expectations and conventions of the sandbox, but must not introduce a | |
476 | separate "sandboxed compilation" interface separate from the CLI interface | |
477 | without going through the normal approval process for such an interface. | |
478 | Such an interface should take into account potential other targets with | |
479 | similar sandboxes. | |
480 | - If the host tools for the platform would normally be expected to be signed or | |
481 | equivalent (e.g. if running unsigned binaries or similar involves a | |
482 | "developer mode" or an additional prompt), it must be possible for the Rust | |
483 | project's automated builds to apply the appropriate signature process, | |
484 | without any manual intervention by either Rust developers, target | |
485 | maintainers, or a third party. This process must meet the approval of the | |
486 | infrastructure team. | |
487 | - This process may require one-time or semi-regular manual steps by the | |
488 | infrastructure team, such as registration or renewal of a signing key. Any | |
489 | such manual process must meet the approval of the infrastructure team. | |
490 | - This process may require the execution of a legal agreement with the | |
491 | signature provider. Such a legal agreement may be revocable, and may | |
492 | potentially require a nominal fee, but must not be otherwise onerous. Any | |
493 | such legal agreement must meet the approval of the infrastructure team. | |
494 | (The infrastructure team is not expected or required to sign binding legal | |
495 | agreements on behalf of the Rust project; this review and approval exists | |
496 | to ensure no terms are onerous or cause problems for infrastructure, | |
497 | especially if such terms may impose requirements or obligations on people | |
498 | who have access to target-specific infrastructure.) | |
499 | - Changes to this process, or to any legal agreements involved, may | |
500 | cause a target to stop meeting this requirement. | |
501 | - This process involved must be available under substantially similar | |
502 | non-onerous terms to the general public. Making it available exclusively to | |
503 | the Rust project does not suffice. | |
504 | - This requirement exists to ensure that Rust builds, including nightly | |
505 | builds, can meet the necessary requirements to allow users to smoothly run | |
506 | the host tools. | |
507 | - Providing host tools does not exempt a target from requirements to support | |
508 | cross-compilation if at all possible. | |
509 | - All requirements for tier 2 apply. | |
510 | ||
511 | A target may be promoted directly from tier 3 to tier 2 with host tools if it | |
512 | meets all the necessary requirements, but doing so may introduce substantial | |
513 | additional complexity. If in doubt, the target should qualify for tier 2 | |
514 | without host tools first. | |
515 | ||
516 | ## Tier 1 target policy | |
517 | ||
518 | At this tier, the Rust project guarantees that a target builds and passes all | |
519 | tests, and will reject patches that fail to build or pass the testsuite on a | |
520 | target. We hold tier 1 targets to our highest standard of requirements. | |
521 | ||
522 | A proposed new tier 1 target must be reviewed and approved by the compiler team | |
523 | based on these requirements. In addition, the release team must approve the | |
524 | viability and value of supporting the target. For a tier 1 target, this will | |
525 | typically take place via a full RFC proposing the target, to be jointly | |
526 | reviewed and approved by the compiler team and release team. | |
527 | ||
528 | In addition, the infrastructure team must approve the integration of the target | |
529 | into Continuous Integration (CI), and the tier 1 CI-related requirements. This | |
530 | review and approval may take place in a PR adding the target to CI, by an | |
531 | infrastructure team member reporting the outcome of a team discussion, or by | |
532 | including the infrastructure team in the RFC proposing the target. | |
533 | ||
534 | - Tier 1 targets must have substantial, widespread interest within the | |
535 | developer community, and must serve the ongoing needs of multiple production | |
536 | users of Rust across multiple organizations or projects. These requirements | |
537 | are subjective, and determined by consensus of the approving teams. A tier 1 | |
538 | target may be demoted or removed if it becomes obsolete or no longer meets | |
539 | this requirement. | |
540 | - The target maintainer team must include at least 3 developers. | |
541 | - The target must build and pass tests reliably in CI, for all components that | |
542 | Rust's CI considers mandatory. | |
543 | - The target must not disable an excessive number of tests or pieces of tests | |
544 | in the testsuite in order to do so. This is a subjective requirement. | |
545 | - If the target does not have host tools support, or if the target has low | |
546 | performance, the infrastructure team may choose to have CI cross-compile | |
547 | the testsuite from another platform, and then run the compiled tests | |
548 | either natively or via accurate emulation. However, the approving teams may | |
549 | take such performance considerations into account when determining the | |
550 | viability of the target or of its host tools. | |
551 | - The target must provide as much of the Rust standard library as is feasible | |
552 | and appropriate to provide. For instance, if the target can support dynamic | |
553 | memory allocation, it must provide an implementation of `alloc` and the | |
554 | associated data structures. | |
555 | - Building the target and running the testsuite for the target must not take | |
556 | substantially longer than other targets, and should not substantially raise | |
557 | the maintenance burden of the CI infrastructure. | |
558 | - In particular, if building the target takes a reasonable amount of time, | |
559 | but the target cannot run the testsuite in a timely fashion due to low | |
560 | performance of either native code or accurate emulation, that alone may | |
561 | prevent the target from qualifying as tier 1. | |
562 | - If running the testsuite requires additional infrastructure (such as physical | |
563 | systems running the target), the target maintainers must arrange to provide | |
564 | such resources to the Rust project, to the satisfaction and approval of the | |
565 | Rust infrastructure team. | |
566 | - Such resources may be provided via cloud systems, via emulation, or via | |
567 | physical hardware. | |
568 | - If the target requires the use of emulation to meet any of the tier | |
569 | requirements, the approving teams for those requirements must have high | |
570 | confidence in the accuracy of the emulation, such that discrepancies | |
571 | between emulation and native operation that affect test results will | |
572 | constitute a high-priority bug in either the emulation or the | |
573 | implementation of the target. | |
574 | - If it is not possible to run the target via emulation, these resources must | |
575 | additionally be sufficient for the Rust infrastructure team to make them | |
576 | available for access by Rust team members, for the purposes of development | |
577 | and testing. (Note that the responsibility for doing target-specific | |
578 | development to keep the target well maintained remains with the target | |
579 | maintainers. This requirement ensures that it is possible for other | |
580 | Rust developers to test the target, but does not obligate other Rust | |
581 | developers to make target-specific fixes.) | |
582 | - Resources provided for CI and similar infrastructure must be available for | |
583 | continuous exclusive use by the Rust project. Resources provided | |
584 | for access by Rust team members for development and testing must be | |
585 | available on an exclusive basis when in use, but need not be available on a | |
586 | continuous basis when not in use. | |
587 | - Tier 1 targets must not have a hard requirement for signed, verified, or | |
588 | otherwise "approved" binaries. Developers must be able to build, run, and | |
589 | test binaries for the target on systems they control, or provide such | |
590 | binaries for others to run. (Doing so may require enabling some appropriate | |
591 | "developer mode" on such systems, but must not require the payment of any | |
592 | additional fee or other consideration, or agreement to any onerous legal | |
593 | agreements.) | |
594 | - The Rust project may decide to supply appropriately signed binaries if | |
595 | doing so provides a smoother experience for developers using the target, | |
596 | and a tier 2 target with host tools already requires providing appropriate | |
597 | mechanisms that enable our infrastructure to provide such signed binaries. | |
598 | However, this additional tier 1 requirement ensures that Rust developers | |
599 | can develop and test Rust software for the target (including Rust itself), | |
600 | and that development or testing for the target is not limited. | |
601 | - All requirements for tier 2 apply. | |
602 | ||
603 | A tier 1 target may be demoted if it no longer meets these requirements but | |
604 | still meets the requirements for a lower tier. Any proposal for demotion of a | |
605 | tier 1 target requires a full RFC process, with approval by the compiler and | |
606 | release teams. Any such proposal will be communicated widely to the Rust | |
607 | community, both when initially proposed and before being dropped from a stable | |
608 | release. A tier 1 target is highly unlikely to be directly removed without | |
609 | first being demoted to tier 2 or tier 3. (The amount of time between such | |
610 | communication and the next stable release may depend on the nature and severity | |
611 | of the failed requirement, the timing of its discovery, whether the target has | |
612 | been part of a stable release yet, and whether the demotion or removal can be a | |
613 | planned and scheduled action.) | |
614 | ||
615 | Raising the baseline expectations of a tier 1 target (such as the minimum CPU | |
616 | features or OS version required) requires the approval of the compiler and | |
617 | release teams, and should be widely communicated as well, but does not | |
618 | necessarily require a full RFC. | |
619 | ||
620 | ### Tier 1 with host tools | |
621 | ||
622 | Some tier 1 targets may additionally have binaries built to run on them as a | |
623 | host (such as `rustc` and `cargo`). This allows the target to be used as a | |
624 | development platform, not just a compilation target. | |
625 | ||
626 | A proposed new tier 1 target with host tools must be reviewed and approved by | |
627 | the compiler team based on these requirements. In addition, the release team | |
628 | must approve the viability and value of supporting host tools for the target. | |
629 | For a tier 1 target, this will typically take place via a full RFC proposing | |
630 | the target, to be jointly reviewed and approved by the compiler team and | |
631 | release team. | |
632 | ||
633 | In addition, the infrastructure team must approve the integration of the | |
634 | target's host tools into Continuous Integration (CI), and the CI-related | |
635 | requirements for host tools. This review and approval may take place in a PR | |
636 | adding the target's host tools to CI, by an infrastructure team member | |
637 | reporting the outcome of a team discussion, or by including the infrastructure | |
638 | team in the RFC proposing the target. | |
639 | ||
640 | - Tier 1 targets with host tools should typically include all of the additional | |
641 | tools such as `clippy` and `rustfmt`, unless there is a target-specific | |
642 | reason why a tool cannot possibly make sense for the target. | |
643 | - Unlike with tier 2, for tier 1 we will not exclude specific tools on the | |
644 | sole basis of them being less likely to be used; rather, we'll take that | |
645 | into account when considering whether the target should be at tier 1 with | |
646 | host tools. In general, on any tier 1 target with host tools, people | |
647 | should be able to expect to find and install all the same components that | |
648 | they would for any other tier 1 target with host tools. | |
649 | - Approval of host tools will take into account the additional time required to | |
650 | build the host tools, and the substantial additional storage required for the | |
651 | host tools. | |
652 | - Host tools for the target must have substantial, widespread interest within | |
653 | the developer community, and must serve the ongoing needs of multiple | |
654 | production users of Rust across multiple organizations or projects. These | |
655 | requirements are subjective, and determined by consensus of the approving | |
656 | teams. This requirement will be evaluated independently from the | |
657 | corresponding tier 1 requirement; it is possible for a target to have | |
658 | sufficient interest for cross-compilation, but not have sufficient interest | |
659 | for native compilation. The host tools may be dropped if they no longer meet | |
660 | this requirement, even if the target otherwise qualifies as tier 1. | |
661 | - The host tools must build, run, and pass tests reliably in CI, for all | |
662 | components that Rust's CI considers mandatory. | |
663 | - The target must not disable an excessive number of tests or pieces of tests | |
664 | in the testsuite in order to do so. This is a subjective requirement. | |
665 | - Building the host tools and running the testsuite for the host tools must not | |
666 | take substantially longer than other targets, and should not substantially raise | |
667 | the maintenance burden of the CI infrastructure. | |
668 | - In particular, if building the target's host tools takes a reasonable | |
669 | amount of time, but the target cannot run the testsuite in a timely fashion | |
670 | due to low performance of either native code or accurate emulation, that | |
671 | alone may prevent the target from qualifying as tier 1 with host tools. | |
672 | - Providing host tools does not exempt a target from requirements to support | |
673 | cross-compilation if at all possible. | |
674 | - All requirements for tier 2 targets with host tools apply. | |
675 | - All requirements for tier 1 apply. | |
676 | ||
677 | A target seeking promotion to tier 1 with host tools should typically either be | |
678 | tier 2 with host tools or tier 1 without host tools, to reduce the number of | |
679 | requirements to simultaneously review and approve. | |
680 | ||
681 | In addition to the general process for demoting a tier 1 target, a tier 1 | |
682 | target with host tools may be demoted (including having its host tools dropped, | |
683 | or being demoted to tier 2 with host tools) if it no longer meets these | |
684 | requirements but still meets the requirements for a lower tier. Any proposal | |
685 | for demotion of a tier 1 target (with or without host tools) requires a full | |
686 | RFC process, with approval by the compiler and release teams. Any such proposal | |
687 | will be communicated widely to the Rust community, both when initially proposed | |
688 | and before being dropped from a stable release. | |
17df50a5 XL |
689 | |
690 | [MCP]: https://forge.rust-lang.org/compiler/mcp.html |