Always attempt to invoke xcrun to get the Apple SDK

The exact reasoning why we do not always pass the SDK root when linking
on macOS eludes me, but I suspect it's because we want to support
compiler drivers which do not support the `-isysroot` option.

Since we now pass the SDK root via the environment variable SDKROOT,
compiler drivers that don't support it can just ignore it.

Similarly, since we only warn when xcrun fails, users that expect their
compiler driver to provide the SDK location can do so now.

1 files changed, 8 insertions, 4 deletions

diff --git a/compiler/rustc_codegen_ssa/src/back/link.rs b/compiler/rustc_codegen_ssa/src/back/link.rs
index 49454f2d845..4ebe59dc2a7 100644
--- a/compiler/rustc_codegen_ssa/src/back/link.rs
+++ b/compiler/rustc_codegen_ssa/src/back/link.rs
@@ -3200,11 +3200,15 @@ fn add_apple_sdk(cmd: &mut dyn Linker, sess: &Session, flavor: LinkerFlavor) ->
     let LinkerFlavor::Darwin(cc, _) = flavor else {
         return None;
     };
-    if os == "macos" && cc != Cc::No {
-        // FIXME(madsmtm): Remove this branch.
-        return None;
-    }
 
+    // The default compiler driver on macOS is at `/usr/bin/cc`. This is a trampoline binary that
+    // effectively invokes `xcrun cc` internally to look up both the compiler binary and the SDK
+    // root from the current Xcode installation. When cross-compiling, when `rustc` is invoked
+    // inside Xcode, or when invoking the linker directly, this default logic is unsuitable, so
+    // instead we invoke `xcrun` manually.
+    //
+    // (Note that this doesn't mean we get a duplicate lookup here - passing `SDKROOT` below will
+    // cause the trampoline binary to skip looking up the SDK itself).
     let sdkroot = sess.time("get_apple_sdk_root", || get_apple_sdk_root(sess))?;
 
     if cc == Cc::Yes {