Rollup merge of #108795 - thomcc:x86_64h-target, r=wesleywiser

Add support for the x86_64h-apple-darwin target

See https://github.com/rust-lang/compiler-team/issues/599 for MCP.

r? compiler-team

CC `@BlackHoleFox` who recently overhauled the apple target code in `rustc-target`.

## Target Support Checklist

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

I'm the designated developer.

> - 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. Changing the name of a target can be highly disruptive, especially
>   once the target reaches a higher tier, so getting the name right is important
>   even for a tier 3 target.

This uses the same naming conventions used for the other macOS targets (`-apple-darwin`), combined with the convention used by LLVM for the `x86_64h` targets. LLVM's convention matches the architecture name used when invoking various tools such as `lipo`, `arch`, and (IMO) there's not really a compelling reason to depart from it.

> - Target names should not introduce undue confusion or ambiguity unless
>   absolutely necessary to maintain ecosystem compatibility. For example, if
>   the name of the target makes people extremely likely to form incorrect
>   beliefs about what it targets, the name should be changed or augmented to
>   disambiguate it.

I don't think this is especially likely, although I suppose someone could mistake it for `x86_64-apple-darwin`.

> - If possible, use only letters, numbers, dashes and underscores for the name.
>   Periods (`.`) are known to cause issues in Cargo.

👍

> - 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.
>   - The target must not introduce license incompatibilities.

It does not.

> - Anything added to the Rust repository must be under the standard Rust
>   license (`MIT OR Apache-2.0`).

It is.

> - The target must not cause the Rust tools or libraries built for any other
>   host (even when supporting cross-compilation to the target) to depend
>   on any new dependency less permissive than the Rust licensing policy. This
>   applies whether the dependency is a Rust crate that would require adding
>   new license exceptions (as specified by the `tidy` tool in the
>   rust-lang/rust repository), or whether the dependency is a native library
>   or binary. In other words, the introduction of the target must not cause a
>   user installing or running a version of Rust or the Rust tools to be
>   subject to any new license requirements.

There are no new dependencies that don't also apply to `x86_64-apple-darwin`.

> - Compiling, linking, and emitting functional binaries, libraries, or other
>   code for the target (whether hosted on the target itself or cross-compiling
>   from another target) must not depend on proprietary (non-FOSS) libraries.
>   Host tools built for the target itself may depend on the ordinary runtime
>   libraries supplied by the platform and commonly used by other applications
>   built for the target, but those libraries must not be required for code
>   generation for the target; cross-compilation to the target must not require
>   such libraries at all. For instance, `rustc` built for the target may
>   depend on a common proprietary C runtime library or console output library,
>   but must not depend on a proprietary code generation library or code
>   optimization library. Rust's license permits such combinations, but the
>   Rust project has no interest in maintaining such combinations within the
>   scope of Rust itself, even at tier 3.

This has the same requirements as the other macOS targets (e.g. `x86_64-apple-darwin` and similar).

> - "onerous" here is an intentionally subjective term. At a minimum, "onerous"
>   legal/licensing terms include but are *not* limited to: non-disclosure
>   requirements, non-compete requirements, contributor license agreements
>   (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms,
>   requirements conditional on the employer or employment of any particular
>   Rust developers, revocable terms, any requirements that create liability
>   for the Rust project or its developers or users, or any requirements that
>   adversely affect the livelihood or prospects of the Rust project or its
>   developers or users.

No change here.

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

👍

> - This requirement does not prevent part or all of this policy from being
>   cited in an explicit contract or work agreement (e.g. to implement or
>   maintain support for a target). This requirement exists to ensure that a
>   developer or team responsible for reviewing and approving a target does not
>   face any legal threats or obligations that would prevent them from freely
>   exercising their judgment in such approval, even if such judgment involves
>   subjective matters or goes beyond the letter of these requirements.

👍

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

The standard library tests seem to pass.

> - 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 binaries, or running tests (even if they do not pass), the
>   documentation must explain how to run such binaries or tests for the target,
>   using emulation if possible or dedicated hardware if necessary.

Documentation is provided.

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

Noted. This target is nearly identical to `x86_64-apple-darwin`, so this is
unlikely to cause issues anyway.

> - Backlinks such as those generated by the issue/PR tracker when linking to
>   an issue or PR are not considered a violation of this policy, within
>   reason. However, such messages (even on a separate repository) must not
>   generate notifications to anyone involved with a PR who has not requested
>   such notifications.

👍

> - 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.
>   - In particular, this may come up when working on closely related targets,
>     such as variations of the same architecture with different features. Avoid
>     introducing unconditional uses of features that another variation of the
>     target may not have; use conditional compilation or runtime detection, as
>     appropriate, to let each target run code supported by that target.

👍

3 files changed, 61 insertions, 5 deletions

diff --git a/compiler/rustc_target/src/spec/apple_base.rs b/compiler/rustc_target/src/spec/apple_base.rs
index 5c6dcc0aba9..4c7f64b2078 100644
--- a/compiler/rustc_target/src/spec/apple_base.rs
+++ b/compiler/rustc_target/src/spec/apple_base.rs
@@ -19,6 +19,7 @@ pub enum Arch {
     I386,
     I686,
     X86_64,
+    X86_64h,
     X86_64_sim,
     X86_64_macabi,
     Arm64_macabi,
@@ -36,6 +37,7 @@ impl Arch {
             I386 => "i386",
             I686 => "i686",
             X86_64 | X86_64_sim | X86_64_macabi => "x86_64",
+            X86_64h => "x86_64h",
         }
     }
 
@@ -44,13 +46,13 @@ impl Arch {
             Armv7 | Armv7k | Armv7s => "arm",
             Arm64 | Arm64_32 | Arm64_macabi | Arm64_sim => "aarch64",
             I386 | I686 => "x86",
-            X86_64 | X86_64_sim | X86_64_macabi => "x86_64",
+            X86_64 | X86_64_sim | X86_64_macabi | X86_64h => "x86_64",
         })
     }
 
     fn target_abi(self) -> &'static str {
         match self {
-            Armv7 | Armv7k | Armv7s | Arm64 | Arm64_32 | I386 | I686 | X86_64 => "",
+            Armv7 | Armv7k | Armv7s | Arm64 | Arm64_32 | I386 | I686 | X86_64 | X86_64h => "",
             X86_64_macabi | Arm64_macabi => "macabi",
             // x86_64-apple-ios is a simulator target, even though it isn't
             // declared that way in the target like the other ones...
@@ -67,6 +69,10 @@ impl Arch {
             Arm64_32 => "apple-s4",
             I386 | I686 => "yonah",
             X86_64 | X86_64_sim => "core2",
+            // Note: `core-avx2` is slightly more advanced than `x86_64h`, see
+            // comments (and disabled features) in `x86_64h_apple_darwin` for
+            // details.
+            X86_64h => "core-avx2",
             X86_64_macabi => "core2",
             Arm64_macabi => "apple-a12",
             Arm64_sim => "apple-a12",
@@ -182,8 +188,13 @@ fn deployment_target(var_name: &str) -> Option<(u32, u32)> {
 }
 
 fn macos_default_deployment_target(arch: Arch) -> (u32, u32) {
-    // Note: Arm64_sim is not included since macOS has no simulator.
-    if matches!(arch, Arm64 | Arm64_macabi) { (11, 0) } else { (10, 7) }
+    match arch {
+        // Note: Arm64_sim is not included since macOS has no simulator.
+        Arm64 | Arm64_macabi => (11, 0),
+        // x86_64h-apple-darwin only supports macOS 10.8 and later
+        X86_64h => (10, 8),
+        _ => (10, 7),
+    }
 }
 
 fn macos_deployment_target(arch: Arch) -> (u32, u32) {
@@ -227,7 +238,7 @@ fn link_env_remove(arch: Arch, os: &'static str) -> StaticCow<[StaticCow<str>]>
         // of the linking environment that's wrong and reversed.
         match arch {
             Armv7 | Armv7k | Armv7s | Arm64 | Arm64_32 | I386 | I686 | X86_64 | X86_64_sim
-            | Arm64_sim => {
+            | X86_64h | Arm64_sim => {
                 cvs!["MACOSX_DEPLOYMENT_TARGET"]
             }
             X86_64_macabi | Arm64_macabi => cvs!["IPHONEOS_DEPLOYMENT_TARGET"],
diff --git a/compiler/rustc_target/src/spec/mod.rs b/compiler/rustc_target/src/spec/mod.rs
index 3ee3a8ea227..10d38c34919 100644
--- a/compiler/rustc_target/src/spec/mod.rs
+++ b/compiler/rustc_target/src/spec/mod.rs
@@ -1112,6 +1112,7 @@ supported_targets! {
 
     ("aarch64-apple-darwin", aarch64_apple_darwin),
     ("x86_64-apple-darwin", x86_64_apple_darwin),
+    ("x86_64h-apple-darwin", x86_64h_apple_darwin),
     ("i686-apple-darwin", i686_apple_darwin),
 
     // FIXME(#106649): Remove aarch64-fuchsia in favor of aarch64-unknown-fuchsia
diff --git a/compiler/rustc_target/src/spec/x86_64h_apple_darwin.rs b/compiler/rustc_target/src/spec/x86_64h_apple_darwin.rs
new file mode 100644
index 00000000000..54f7490b2c0
--- /dev/null
+++ b/compiler/rustc_target/src/spec/x86_64h_apple_darwin.rs
@@ -0,0 +1,44 @@
+use super::apple_base::{macos_llvm_target, opts, Arch};
+use crate::spec::{Cc, FramePointer, LinkerFlavor, Lld, SanitizerSet};
+use crate::spec::{StackProbeType, Target, TargetOptions};
+
+pub fn target() -> Target {
+    let arch = Arch::X86_64h;
+    let mut base = opts("macos", arch);
+    base.max_atomic_width = Some(128);
+    base.frame_pointer = FramePointer::Always;
+    base.add_pre_link_args(LinkerFlavor::Darwin(Cc::Yes, Lld::No), &["-m64"]);
+    base.stack_probes = StackProbeType::X86;
+    base.supported_sanitizers =
+        SanitizerSet::ADDRESS | SanitizerSet::CFI | SanitizerSet::LEAK | SanitizerSet::THREAD;
+
+    // x86_64h is core2-avx without a few of the features which would otherwise
+    // be guaranteed, so we need to disable those. This imitates clang's logic:
+    // - https://github.com/llvm/llvm-project/blob/bd1f7c417/clang/lib/Driver/ToolChains/Arch/X86.cpp#L77-L78
+    // - https://github.com/llvm/llvm-project/blob/bd1f7c417/clang/lib/Driver/ToolChains/Arch/X86.cpp#L133-L141
+    //
+    // FIXME: Sadly, turning these off here disables them in such a way that they
+    // aren't re-enabled by `-Ctarget-cpu=native` (on a machine that has them).
+    // It would be nice if this were not the case, but fixing it seems tricky
+    // (and given that the main use-case for this target is for use in universal
+    // binaries, probably not that important).
+    base.features = "-rdrnd,-aes,-pclmul,-rtm,-fsgsbase".into();
+    // Double-check that the `cpu` is what we expect (if it's not the list above
+    // may need updating).
+    assert_eq!(
+        base.cpu, "core-avx2",
+        "you need to adjust the feature list in x86_64h-apple-darwin if you change this",
+    );
+
+    Target {
+        // Clang automatically chooses a more specific target based on
+        // MACOSX_DEPLOYMENT_TARGET. To enable cross-language LTO to work
+        // correctly, we do too.
+        llvm_target: macos_llvm_target(arch).into(),
+        pointer_width: 64,
+        data_layout: "e-m:o-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+            .into(),
+        arch: arch.target_arch(),
+        options: TargetOptions { mcount: "\u{1}mcount".into(), ..base },
+    }
+}