Promote aarch64-apple-ios-sim to Tier 2

[badboy]

Proposal

I propose to promote the aarch64-apple-ios-sim target to Tier 2.
That target was introduced in PR #81966, by @deg4uss3r and myself.

Currently to build libraries/applications for iOS and run them in the iOS simulator on aarch64 macOS hardware one can use Nightly and build with -Z build-std --target aarch64-apple-ios-sim.
With this target be Tier 2 the required artifacts will be shipped through rustup, and compilation will be possible on Release.

The aarch64-apple-ios-sim targets the iOS simulator on macOS aarch64 machines.
It is similar to the already existing x86_64-apple-ios and aarch64-apple-ios targets (which are Tier 2).
It is required because aarch64-apple-ios is only for iOS hardware.
It is required on newer macOS aarch64 machines (also known as M1 or Apple silicon) to build for the iOS simulator.
The underlying LLVM target (arm64-apple-ios14.0-simulator) ensures that host libraries from the correct SDK are picked,
instead of the iOS hardware target (arm64-apple-ios).

Below the different requirements from the Tier 2 target policy are addressed.

---

A tier 2 target must have value to people other than its maintainers. (It may still be a niche target, but it must not be exclusively useful for an inherently closed group.)

It's useful for anyone on aarch64 macOS machines, targeting and testing iOS software.

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.

• @badboy
• @deg4uss3r
• The same set of people currently responsible for aarch64-apple-ios and x86_64-apple-ios

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

This target does not place any additional burden on Rust developers beyond what's already required by aarch64-apple-ios and x86_64-apple-ios.

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.

[TODO: Where do we need to document this?]

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

Requires Xcode 12+ on macOS.
Otherwise equivalent to x86_64-apple-ios I suppose.

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.

New target with new underlying LLVM target.
Required on macOS aarch64 machines, because the underlying tooling requires different SDKs (and thus libraries).

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.

core is implemented for target_os = "ios", which applies here equally.

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

Should be the same code generation backend as for aarch64-apple-ios, thus no deficiencies beyond that.

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 C calling convention does not need to be the default Rust calling convention for the target, however.

Same as aarch64-apple-ios.

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

Can't verify that before we tried it.
I don't expect challenges.

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

Simulator target. Would require to run on M1 hardware.
Code in core or std should only check target_os = "ios", so if that's tested in the other targets already, we should be good without it here.

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.

Can't verify that before we tried it.
Can probably be build on x86_64 macOS machines.

Tier 2 targets should, if at all possible, support cross-compiling. Tier 2 targets should not require using the target as the host for builds, even if the target supports host tools.

Building on x86_64 macOS should work.

In addition to the legal requirements for all targets (specified in the tier 3 requirements) 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 [...]

No changes.
Same requirements as aarch64-apple-ios and x86_64-apple-ios

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.

target_os = "ios" already exists.
This target does not introduce any burden beyond that.

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

[TODO: Uhm, ok.]

All requirements for tier 3 apply.

aarch64-apple-ios-sim is tier 3 right now.
While introduced before the written target policy was published, it should fulfill all requirements there,
as it's mostly a fork of an even older target.

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention then
here. You can put your own name here if you are planning to mentor the
work.

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.

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

[jyn514]

@badboy I tried to answer some of your questions on Zulip but you don't seem to be part of the server - do you mind joining? Github is not great for extended discussions (and also it will divide comments between here and zulip).

https://rust-lang.zulipchat.com/#narrow/stream/233931-xxx/topic/Promote.20.60aarch64-apple-ios-sim.60.20to.20Tier.202.20compiler-team.23428

[badboy]

Pinged you, I'm on that server, just under a different nick (should have figured that before...)

[badboy]

As requested on Zulip, in the following are answers to the Tier 3 requirements.

tl;dr: We're nearly good, I'll send a PR for documentation updates (tackling both Tier 3 and 2 requirements)

A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)

• @badboy
• @deg4uss3r
• The same set of people currently responsible for aarch64-apple-ios and x86_64-apple-ios

Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge.

Existing targets + -sim suffix.
However the LLVM target is suffixed with -simulator.
This could still be changed in Rust right now. Either way would be fine IMO.

Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.

Same as existing iOS targets.

Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.

None that I'm aware off.
This falls in the same category as already existing iOS targets.

Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.

Same as existing iOS targets, core and libstd are already implemented for target_os = "ios".

The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary.

I will see to get that documentation added.
On Zulip it was suggested to keep that also in the rustc book, so I'm preparing a PR for that.

Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via @) to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.

Existing iOS targets are already Tier 2, and thus block landing if it doesn't build. Nothing changes for this new target.

Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.

Only overlaps with already existing iOS targets, which are Tier 2, so no further breakage expteded.

[pnkfelix]

@rustbot second

[apiraino]

rustbot seems having forgot to ...

@rustbot label +final-comment-period

[apiraino]

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