Get the GBA targets to Tier 2

[Lokathor]

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]

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?

[Lokathor]

With no response, I'll ping @gwilymk and @corwinkuiper as well, since you two are the listed owners of the agb crate. Would either of you two care to be listed as a second maintainer for the two GBA targets so we can qualify for Tier 2?

[corwinkuiper]

What does being a maintainer entail? I'm no rust compiler expert / LLVM wrangler, so I'm not sure I could be much use.

[Lokathor]

Basically it's no work at all. Other than the time I initially added the target entry file I've basically never had to do an update. I got ping'd once to sign off on some documentation updates that affected several targets, but I didn't even have to actually wrangle code.

The ARMv4T targets are extremely old, which means that they're also basically "settled" at this point, and there's no updates to keep up with or anything like that like some other targets (eg: for WASM or MacOS or whatever).

[corwinkuiper]

I reckon I should be able to be a listed maintainer in that case.

[Lokathor]

Alright, I opened a PR to add you, https://github.com/rust-lang/rust/pull/126003, if you could leave a comment there.

[Lokathor]

updated the opening to be a checkbox list of our goals. the main thing to handle before we can open an MCP is to document how to do automated testing.

[corwinkuiper]

What is the test suite?

[Lokathor]

presumably some or all of the tests described here, https://rustc-dev-guide.rust-lang.org/tests/intro.html

The compiletest part, and the package test for core

[corwinkuiper]

From the name compiletest is hopefully not too bad, I'd need to look into how to run core's tests. I need to relook at test running in general considering the custom_test_framework feature's tracking issue is now closed.

[Lokathor]

I spoke to Josh T. and they said it's still the best we've got, so basically we should keep using it for now even though some day we'll have to switch to some new framework (once someone designs the next framework).