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