Get the GBA targets to Tier 2

Lokathor commented 5 months ago

We use many nightly things, but most of them could be pulled out if necessary. However, build-std can't be worked around, and it also isn't likely to become stable any time soon.

But if we can get our GBA target promoted to Tier 2, then we won't need build-std.

Quoting https://doc.rust-lang.org/rustc/target-tier-policy.html#tier-2-target-policy:

[x] A tier 2 target must have value to people other than its maintainers.
[x] A tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers.
[x] The target must not place undue burden on Rust developers not specifically concerned with that target.
[ ] The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run tests for the target.
[x] The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.
[x] If introducing a new tier 2 or higher target that is identical to an existing Rust target except for the baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar, then the proposed target must document to the satisfaction of the approving teams why the specific difference in baseline expectations provides sufficient value to justify a separate target.
[x] Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target.
[x] The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team.
[x] If the target supports C code, and the target has an interoperable calling convention for C code, the Rust target must support that C calling convention for the platform via extern "C".
[x] The target must build reliably in CI, for all components that Rust's CI considers mandatory.
[x] The approving teams may additionally require that a subset of tests pass in CI, such as enough to build a functional "hello world" program, ./x.py test --no-run, or equivalent "smoke tests".
[x] Building the target in CI must not take substantially longer than the current slowest target in CI, and should not substantially raise the maintenance burden of the CI infrastructure.
[x] Tier 2 targets should, if at all possible, support cross-compiling.
[x] In addition to the legal requirements for all targets (specified in the tier 3 requirements), because a tier 2 target typically involves the Rust project building and supplying various compiled binaries, incorporating the target and redistributing any resulting compiled binaries (e.g. built libraries, host tools if any) must not impose any onerous license requirements on any members of the Rust project, including infrastructure team members and those operating CI systems.
[x] Tier 2 targets must not impose burden on the authors of pull requests, or other developers in the community, to ensure that tests pass for the target.
[ ] The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion.

Lokathor commented 5 months ago

Hey @QuinnPainter you're listed as the maintainer for armv5te-none-eabi, which the target docs mention as being for the DS. Would you want to team up so that you're added as a v4T maintainer, and I'm added as a v5TE maintainer, and then both our targets would qualify for being in Tier 2?