Add target_env = "macabi" and target_env = "sim"

[madsmtm]

RFC 2992 (tracking issue) introduced cfg(target_abi = ...) with the original motivation being Mac Catalyst and Apple Simulator targets. These do not actually have a changed calling convention in the same sense that e.g. cfg(target_abi = "eabihf") or pointer authentication (arm64e) does, see #133331.

Specifically, for Apple Simulator targets, the binary runs under the following conditions:

• Runs with the host macOS kernel (but in a mode configured for iOS/tvOS/...).
• Uses frameworks for the specific simulator version being targetted.
• System file accesses need to be made relative to the IPHONE_SIMULATOR_ROOT environment variable.
• Uses host GPUs directly.

And for Mac Catalyst:

• Runs with the host macOS kernel (but in a mode configured for iOS).
• Uses mostly host macOS frameworks (though with a few things changed, e.g. the NSImageResizingModeStretch enum has a different value).
• Uses host GPUs, camera and other peripherals directly.

As can be seen, these seem better suited as target_envs, since it really is the environment that the binary is running under that's changed (regardless of the Mac Catalyst "macabi" having "abi" in the name). So this PR adds target_env = "sim" and target_env = "macabi", with the idea of possibly deprecating target_abi = "sim" and target_abi = "macabi" in the far future.

This is affects iOS Tier 2 targets (aarch64-apple-ios-sim, x86_64-apple-ios, aarch64-apple-ios-macabi and x86_64-apple-ios-macabi), and probably needs a compiler FCP.

Fixes #133331.
Reference PR: rust-lang/reference#1781.
Cargo doc PR: rust-lang/cargo#15404.

r? compiler
CC @workingjubilee
CC target maintainers @deg4uss3r @thomcc @badboy @BlackHoleFox @madsmtm @agg23

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[SparrowLii]

It looks fine, but I'm not familar with target options so
r? @workingjubilee since this is from #133331

[workingjubilee]

Hm. Reviewing https://github.com/rust-lang/rust-forge/blob/master/src/compiler/proposals-and-stabilization.md#targets this is an unspecified case for approving changes to targets, cc @davidtwco and @wesleywiser

But it is user-facing, I suppose, so an FCP does make sense. Tentatively applying labels assuming that is correct.

[apiraino]

I'm also not very familiar with target options but I feel that target_env = "sim" is a bit generic. Would it make sense something that says more explicitly that this is an Apple thing? Example target_env = "ios-sim" or something along this line?

[wesleywiser]

Yes, I think an FCP is appropriate for this change.

@rfcbot fcp merge

[rfcbot]

Team member @wesleywiser has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Mark-Simulacrum
• @Noratrieb
• @SparrowLii
• @cjgillot
• @compiler-errors
• @davidtwco
• @estebank
• @matthewjasper
• @nagisa
• @oli-obk
• @petrochenkov
• @spastorino
• @wesleywiser

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[madsmtm]

I'm also not very familiar with target options but I feel that target_env = "sim" is a bit generic. Would it make sense something that says more explicitly that this is an Apple thing? Example target_env = "ios-sim" or something along this line?

I'm very against other naming here, reasoning outlined in rust-lang/compiler-team#850.

[workingjubilee]

We already have the "the same cfg name can be present for two targets" problem, unfortunately, due to target_feature.

[Mark-Simulacrum]

Should we recommend something like cfg!(all(target_vendor = "apple", target_env = "sim")) here to avoid overlap bugs?

[madsmtm]

Perhaps? Or maybe the example should be:

#![cfg(target_vendor = "apple")]

if cfg!(target_env = "sim") {
    // ...
}

As I expect that kind of pattern to be the most common (e.g. you need to differentiate the simulator while you're already in the context of iOS / Apple).

[BlackHoleFox]

Unsure if the module cfg makes sense; I've seen uses where in the simulator might just need a branch skipped, or a different branch taken, but the same block of code is being ran for multiple OSes instead of just Apple ones so you see this pattern:

if cfg!(all(target_vendor = "apple", target_env = "sim")) {
    // Do easier, simulator specific thing that still has cross-platform abstraction
    ...
} {
    // Everything else, like Windows and non-simulator iOS via cross-platform abstraction.
    ...
}