rules_swift patch: point macOS platform_lib_dir at usr/lib/swift/macosx

Swift.org macOS toolchains store their runtime libraries under
usr/lib/swift/macosx/ (Apple's SDK name), not usr/lib/swift/macos/
(the Bazel @platforms//os:macos name). rules_swift 4.0.0-rc4's
_swift_unix_linkopts_cc_info uses the latter, causing -L to point at
a non-existent directory and ld to fail with undefined
swiftCompatibility{56,Concurrency,Packs} symbols on macOS.

Rewrite platform_lib_dir to `usr/lib/swift/macosx` on the macOS branch
of the existing patch so the -L / -Wl,-rpath resolve to a real dir
that already gets materialized into the sandbox via swift_tools'
`additional_inputs = glob(["usr/lib/swift/**", ...])`.

Author: Copilot

misc/bazel/patches/rules_swift/macos-linkopts.patch

@@ -1,34 +1,64 @@
-Skip Linux-only linkopts when generating macOS Swift toolchain linker inputs.
+Emit macOS-appropriate linkopts when generating macOS Swift toolchain
+linker inputs.
 
 rules_swift 4.0.0-rc4's standalone toolchain extension registers a
-`swift_toolchain(...)` for macOS whose implicit linker inputs are produced by
-`_swift_unix_linkopts_cc_info`. That function unconditionally emits
-Linux/ELF-only flags -- `swiftrt.o`, `-lstdc++`, `-lrt`, `-ldl`,
-`-static-libgcc` -- plus a Linux-shaped runtime path
-(`{arch}/swiftrt.o` with `arch = "aarch64"`, but the macOS toolchain lays
-out `usr/lib/swift/macos/` without `swiftrt.o` at all and uses `arm64` for
-Apple Silicon).
+`swift_toolchain(...)` for macOS whose implicit linker inputs are produced
+by `_swift_unix_linkopts_cc_info`. That function has two problems on macOS:
 
-On macOS the Apple linker handles Swift runtime initialization automatically
-via `LC_LINKER_OPTION` autolinking and `__DATA,__mod_init_func`, so
-`swiftrt.o` is neither present nor needed. The other flags are also
-Linux-specific. The only linkopts that carry over are the toolchain library
-search path and rpath so downstream binaries can locate
-`libswiftCore.dylib` etc.
+1. It unconditionally emits Linux/ELF-only flags -- `swiftrt.o`,
+   `-lstdc++`, `-lrt`, `-ldl`, `-static-libgcc` -- plus a Linux-shaped
+   runtime path (`{arch}/swiftrt.o` with `arch = "aarch64"`, but the
+   macOS toolchain lays out `usr/lib/swift/macosx/` without `swiftrt.o`
+   at all and uses `arm64` for Apple Silicon).
 
-Without this patch, linking any `swift_library`-dependent Rust binary (e.g.
-`//unified/swift-syntax-rs:swift-syntax-parse`) on macOS fails with:
+2. It builds the Swift runtime library path as
+   `{toolchain_root}/lib/swift/{os}` using the `os` value passed in from
+   `_swift_toolchain_impl`, which is `"macos"` (the Bazel
+   `@platforms//os:macos` name). But a Swift.org macOS toolchain -- the
+   one rules_swift materializes via `swift_tools`' `additional_inputs =
+   glob(["usr/lib/swift/**", ...])` -- actually stores its libraries
+   under `usr/lib/swift/`**`macosx`**`/` (Apple's SDK name), not
+   `usr/lib/swift/macos/`. `-L .../usr/lib/swift/macos` therefore points
+   at a non-existent directory, so `libswiftCompatibility56.a`,
+   `libswiftCompatibilityConcurrency.a`,
+   `libswiftCompatibilityPacks.a` (auto-linked via `LC_LINKER_OPTION`
+   records in swiftc-emitted `.o` files) can't be resolved, and their
+   symbols end up undefined.
+
+On macOS the Apple linker handles Swift runtime initialization
+automatically via `LC_LINKER_OPTION` autolinking and
+`__DATA,__mod_init_func`, so `swiftrt.o` is neither present nor needed.
+The Linux-specific system libraries (`-lrt`, `-ldl`, `-lstdc++`,
+`-static-libgcc`) also don't exist. The only linkopts that carry over
+are the toolchain library search path and rpath -- rewritten to point
+at `macosx` -- so downstream binaries can locate `libswiftCore.dylib`
+and the compatibility static archives.
+
+Without this patch, linking any `swift_library`-dependent Rust binary
+(e.g. `//unified/swift-syntax-rs:swift-syntax-parse`) on macOS fails
+with either:
 
     clang: error: no such file or directory:
       'external/rules_swift+.../usr/lib/swift/macos/aarch64/swiftrt.o'
 
-This should be fixed upstream: rules_swift's standalone toolchain extension
-needs a macOS-aware `_swift_unix_linkopts_cc_info`. Until then, we patch the
-module locally so macOS consumers can build.
+(problem 1, pre-patch), or:
+
+    ld: warning: search path
+      'external/rules_swift+.../usr/lib/swift/macos' not found
+    ld: warning: Could not find or use auto-linked library
+      'swiftCompatibility56': library 'swiftCompatibility56' not found
+    Undefined symbols for architecture arm64: ...
+    ld: symbol(s) not found for architecture arm64
+
+(problem 2, if only problem 1 is fixed).
+
+This should be fixed upstream: rules_swift's standalone toolchain
+extension needs a macOS-aware `_swift_unix_linkopts_cc_info`. Until
+then, we patch the module locally so macOS consumers can build.
 
 --- a/swift/toolchains/swift_toolchain.bzl
 +++ b/swift/toolchains/swift_toolchain.bzl
-@@ -411,25 +411,38 @@
+@@ -411,25 +411,48 @@
          toolchain_root = toolchain_root,
      )
 
@@ -57,9 +87,19 @@ module locally so macOS consumers can build.
 +        # __DATA,__mod_init_func; swiftrt.o is neither present in the
 +        # toolchain layout nor needed. The Linux-specific system libraries
 +        # (-lrt, -ldl, -lstdc++, -static-libgcc) also don't exist here.
++        #
++        # Also, a Swift.org macOS toolchain stores its libraries under
++        # `usr/lib/swift/macosx/` (Apple's SDK name), not the Bazel
++        # `os = "macos"` name that `_swift_toolchain_impl` passes in. Rewrite
++        # `platform_lib_dir` to point at `macosx` so `-L` and `-Wl,-rpath`
++        # resolve to a real directory (and thus `libswiftCompatibility*.a`,
++        # `libswiftCore.dylib`, etc. can be found by the linker).
++        macos_platform_lib_dir = "{toolchain_root}/lib/swift/macosx".format(
++            toolchain_root = toolchain_root,
++        )
 +        linkopts = [
-+            "-L{}".format(platform_lib_dir),
-+            "-Wl,-rpath,{}".format(platform_lib_dir),
++            "-L{}".format(macos_platform_lib_dir),
++            "-Wl,-rpath,{}".format(macos_platform_lib_dir),
 +        ] + [
 +            "-Wl,-rpath,{}".format(rpath)
 +            for rpath in additional_rpaths