Promote Mac Catalyst targets to Tier 2

[madsmtm]

Proposal

This is a proposal to upgrade the Mac Catalyst targets x86_64-apple-ios-macabi and aarch64-apple-ios-macabi (introduced here and here) to Tier 2.

Mac Catalyst is a technology available on macOS that allows running iOS applications natively on the Mac. That makes these rustc targets immensely useful, as it also allows testing iOS-specific code in CI and locally; cargo test --target aarch64-apple-ios-macabi mostly just works (in contrast to the usual iOS targets, which need to be bundled and run on the simulator using a tool like cargo-dinghy).

This is, of course, not a substitute for testing on the iOS simulator, or even better, on a real device, but it's a fairly good one; at every step of the stack, from the compiler, to the linker, the system libraries and finally the kernel, are all configured as-if targetting iOS (albeit with a few more APIs and capabilities available than would otherwise be there).

Apart from the testing benefits, these targets are useful by themselves for users that have an existing iOS / UIKit application that they want to ship on the Mac as well.

Sub-proposal: Running the compiler's test suite on Mac Catalyst

Somewhat separately, though closely related, is that we can use this target in Rust's test suite itself to test that everything work on Mac Catalyst, and by extension, gain more confidence that the code for the existing Tier 2 iOS targets work (as stated above, testing these directly is somewhat burdensome).

I have been slowly working for the past few months on fixing the test suite so that it passes on Mac Catalyst, see rust-lang/rust#124491, rust-lang/rust#124788, rust-lang/rust#125225 and rust-lang/rust#125226. More work is still needed here, but would like to also use this issue to gauge the interest in doing so.

---

Tier 3 Requirements

Since these targets are older than the Target Tier Policy, I'm going to go through the whole ordeal, and make sure that they meet the Tier 3 requirements first (parts omitted for brevity):

A tier 3 target must have a designated developer

I (@madsmtm) am noted as the target maintainer.

Targets must use naming consistent with any existing targets

The naming follows aarch64-apple-ios-sim, and puts the target_abi as the last part of the target.

Must not create legal issues or impose onerous legal terms
[...]
Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party
[...]

Same as for the existing Tier 2 iOS targets; the LLVM parts are open source and having these targets in rustc does not impose any legal requirements.

Tier 3 targets should attempt to implement as much of the standard libraries as possible

The standard library is implemented for these targets.

The target must provide documentation

Documentation is provided in the platform support page for Mac Catalyst.

Tier 3 targets must not impose burden on the authors of pull requests

Understood.

Patches adding or updating tier 3 targets must not break existing targets

Understood.

Tier 3 targets must be able to produce assembly

It can.

---

Tier 2 Requirements

And now we can take a look at the Tier 2 requirements:

A tier 2 target must have value to people other than its maintainers

It does, the benefits are outlined in the top of this issue.

A tier 2 target must have a designated team of developers. This team must have at least 2 developers.

TODO. This requirement is not yet met, since the target pages were only recently cleaned up, and maintainers weren't written down before then.

Tagging people that might possibly be interested in being co-maintainer of these targets with me (@madsmtm):

• @badboy, since you maintain the other iOS targets.
• @thomcc, since you maintain other Apple targets.
• @terhechte, as you're the original implementer of these targets.
• @BlackHoleFox, since you've done work on Apple targets in the fairly recent past.

EDIT: Fixed in rust-lang/rust#126586.

• The target maintainers should not only fix target-specific issues, but should use any such issue as an opportunity to educate the Rust community about portability to their target, and enhance documentation of the target.

Understood.

The target must not place undue burden on Rust developers not specifically concerned with that target

The maintenance burden of promoting these targets to tier 2 should be fairly minor, as the very similar aarch64-apple-ios and x86_64-apple-ios targets are already Tier 2.

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. If at all possible, this documentation should show how
to run Rust programs and tests for the target using emulation, to allow
anyone to do so. If the target cannot be feasibly emulated, the documentation
should explain how to obtain and work with physical hardware, cloud systems,
or equivalent.

Documentation is provided in the platform support page for Mac Catalyst.

The target is already emulating another system (iOS), and can only (realistically) be run on Mac hardware.

The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.

OS requirements and build system requirements are documented on the aforementioned platform support page.

If introducing a 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.

These targets target Mac Catalyst, which is a distinct mode the macOS operating system can operate in, and the targets cannot be combined with the existing Tier 2 iOS targets.

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 full standard library is implemented for these targets (and is in fact better supported than on the existing Tier 2 iOS targets, as they run on the macOS kernel, which is less restrictive than iOS).

The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team.

Signal handlers are not enabled on this target due to fear of being rejected from the App Store (same as the existing Tier 2 iOS targets), but stack probes are, which should prevent safe code from being able to overflow the stack.

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".

These targets support C code and the C calling convention that Rust uses works with these targets.

The target must build reliably in CI, for all components that Rust's CI considers mandatory.

The targets are not yet configured to build in CI, will do that in a follow-up PR.
EDIT: Done.

They should be just as reliable as the existing Tier 2 iOS targets.

The approving teams may additionally require that a subset of tests pass in CI

See the sub-proposal above.

Building the target in CI must not take substantially longer than the current slowest target in CI

The targets are likely to build in the same amount of time as the existing Tier 2 iOS targets.

Tier 2 targets should support cross-compiling

The targets support cross-compiling (though you must have the Xcode SDK available).

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.

I'm a bit unsure of the legality here, but it should be the same as for the existing Tier 2 iOS targets.

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.

Understood.

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

Understood. See also the sub-proposal above for

All requirements for tier 3 apply.

They do, see above.

---

Mentors or Reviewers

@workingjubilee has been reviewing most of the PRs inching the test suite closer to passing, and @thomcc is (from my understanding) the current Apple expert on the library team.

Just to make sure we follow procedure, someone might also want to ping the Apple Notification Group (I don't have the rights to do it myself).

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:

@rustbot concern reason-for-concern 
<description of the concern> 

Concerns can be lifted with:

@rustbot resolve reason-for-concern 

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler @rust-lang/compiler-contributors

[badboy]

Tagging people that might possibly be interested in being co-maintainer of these targets with me (@madsmtm):

* @badboy, since you maintain the other iOS targets.

Sure! Time so far getting pinged on the other iOS targets is ... 0 I think. I can sign up for one more target.

[madsmtm]

I have added @BlackHoleFox and @badboy as target maintainers in rust-lang/rust#126586, so that should now also be resolved (thanks both of you!).

[wesleywiser]

@rustbot second

@madsmtm thanks for your efforts to get the test suite working on these targets! I think it would be great to have that testing in CI but I think that decision falls to T-infra. I would suggest starting a thread on their channel about the idea.

[apiraino]

@rustbot label -final-comment-period +major-change-accepted