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:

• A tier 2 target must have value to people other than its maintainers.
• 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.
• 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.
• The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.
• 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.
• 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.
• The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team.
• 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".
• The target must build reliably in CI, for all components that Rust's CI considers mandatory.
• 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".
• 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.
• Tier 2 targets should, if at all possible, support cross-compiling.
• 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.
• 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, rust-lang/rust#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).

[Anders429]

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.

Would the README for gba_test be sufficient for documenting how to run tests? It explains how to build and run tests using the framework with mgba, mgba-rom-test, or real hardware. Running with mgba-rom-test has proven to be sufficient for setting up continuous integration for GBA projects so far, and running on normal mgba works just fine for cargo test.

The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion.

I mentioned this elsewhere already, but I did get nearly all of the Rust coretests test suite running with gba_test (repo here). The parts I couldn't actually include either relied on parts of std that I can't actually support (like multiple threads, unsupported atomic functions, unsupported log functions, catching unwinding panics, etc.) or things that were too big to run on GBA (these are almost all the same tests that are marked to not run on miri either). I'll reiterate my concerns with this test suite here:

• coretests tests a lot of nightly features, which means that the tests change as the nightly features change.
• In order to get this to work, I had to import the gba_test::test attribute in basically every module, as well as import whatever was used from core and alloc (and change a lot of imports to not import stuff from std). This was fine for a one-off run, but I am unsure of how easy it would be to continually rebase on to the actual coretests without it being an annoying maintenance burden.
  • If the imports could be changed in the Rust repo to just import everything it can from core and alloc, it would make this a lot easier. Right now it seems like a mix between the two, with a strong reliance on the std prelude as well. Then we would only need to worry about keeping up with which tests can't actually run on GBA.

Overall it was surprisingly harder than I thought to get the core test suite to actually run on a no_std target. The tests seem to be built to just test the library in a normal test environment instead. That said, it's not completely undoable, but I'm interested in figuring out how to make it as easy as possible.