Merge pull request #71844 from al45tair/eng/PR-123506306

Add support to the compiler for musl and the LINUX_STATIC SDK.

Author: al45tair

lib/Basic/Platform.cpp

@@ -231,7 +231,17 @@ StringRef swift::getPlatformNameForTriple(const llvm::Triple &triple) {
   case llvm::Triple::XROS:
     return getPlatformNameForDarwin(getDarwinPlatformKind(triple));
   case llvm::Triple::Linux:
-    return triple.isAndroid() ? "android" : "linux";
+    if (triple.isAndroid())
+      return "android";
+    else if (triple.isMusl()) {
+      // The triple for linux-static is <arch>-swift-linux-musl, to distinguish
+      // it from a "normal" musl set-up (ala Alpine).
+      if (triple.getVendor() == llvm::Triple::Swift)
+        return "linux-static";
+      else
+        return "musl";
+    } else
+      return "linux";
   case llvm::Triple::FreeBSD:
     return "freebsd";
   case llvm::Triple::OpenBSD:

lib/ClangImporter/ClangImporter.cpp

@@ -646,7 +646,7 @@ void importer::getNormalInvocationArguments(
     // using Glibc or a libc that respects that flag. This will cause some
     // source breakage however (specifically with strerror_r()) on Linux
     // without a workaround.
-    if (triple.isOSFuchsia() || triple.isAndroid()) {
+    if (triple.isOSFuchsia() || triple.isAndroid() || triple.isMusl()) {
       // Many of the modern libc features are hidden behind feature macros like
       // _GNU_SOURCE or _XOPEN_SOURCE.
       invocationArgStrs.insert(invocationArgStrs.end(), {

lib/ClangImporter/ClangIncludePaths.cpp

@@ -180,7 +180,7 @@ createClangArgs(const ASTContext &ctx, clang::driver::Driver &clangDriver) {
 
 static bool shouldInjectLibcModulemap(const llvm::Triple &triple) {
   return triple.isOSGlibc() || triple.isOSOpenBSD() || triple.isOSFreeBSD() ||
-         triple.isAndroid() || triple.isOSWASI();
+         triple.isAndroid() || triple.isMusl() || triple.isOSWASI();
 }
 
 static SmallVector<std::pair<std::string, std::string>, 2>
@@ -254,8 +254,9 @@ static void getLibStdCxxFileMapping(
   // We currently only need this when building for Linux.
   if (!triple.isOSLinux())
     return;
-  // Android uses libc++.
-  if (triple.isAndroid())
+  // Android uses libc++, as does our fully static Linux config.
+  if (triple.isAndroid()
+      || (triple.isMusl() && triple.getVendor() == llvm::Triple::Swift))
     return;
 
   // Extract the libstdc++ installation path from Clang driver.
@@ -529,30 +530,44 @@ ClangInvocationFileMapping swift::getClangInvocationFileMapping(
 
   const llvm::Triple &triple = ctx.LangOpts.Target;
 
+  // For modulemaps that have all the C standard library headers together in
+  // a single module, we end up with module cycles with the clang _Builtin_
+  // modules.  e.g. <inttypes.h> includes <stdint.h> on these platforms. The
+  // clang builtin <stdint.h> include-nexts <stdint.h>. When both of those
+  // platform headers are in the SwiftLibc module, there's a module cycle
+  // SwiftLibc -> _Builtin_stdint -> SwiftLibc (i.e. inttypes.h (platform) ->
+  // stdint.h (builtin) -> stdint.h (platform)).
+  //
+  // Until these modulemaps can be fixed, the builtin headers need to join
+  // the system modules to avoid the cycle.
+  //
+  // Note that this does nothing to fix the same problem with C++ headers,
+  // and that this is generally a fragile solution.
+  //
+  // We start by assuming we do *not* need to do this, then enable it for
+  // affected modulemaps.
+  result.requiresBuiltinHeadersInSystemModules = false;
+
   SmallVector<std::pair<std::string, std::string>, 2> libcFileMapping;
   if (triple.isOSWASI()) {
     // WASI Mappings
     libcFileMapping =
         getLibcFileMapping(ctx, "wasi-libc.modulemap", std::nullopt, vfs);
+
+    // WASI's module map needs fixing
+    result.requiresBuiltinHeadersInSystemModules = true;
+  } else if (triple.isMusl()) {
+    libcFileMapping =
+        getLibcFileMapping(ctx, "musl.modulemap", StringRef("SwiftMusl.h"), vfs);
   } else {
     // Android/BSD/Linux Mappings
     libcFileMapping = getLibcFileMapping(ctx, "glibc.modulemap",
                                          StringRef("SwiftGlibc.h"), vfs);
+
+    // glibc.modulemap needs fixing
+    result.requiresBuiltinHeadersInSystemModules = true;
   }
   result.redirectedFiles.append(libcFileMapping);
-  // Both libc module maps have the C standard library headers all together in a
-  // SwiftLibc module. That leads to module cycles with the clang _Builtin_
-  // modules. e.g. <inttypes.h> includes <stdint.h> on these platforms. The
-  // clang builtin <stdint.h> include-nexts <stdint.h>. When both of those
-  // platform headers are in the SwiftLibc module, there's a module cycle
-  // SwiftLibc -> _Builtin_stdint -> SwiftLibc (i.e. inttypes.h (platform) ->
-  // stdint.h (builtin) -> stdint.h (platform)). Until this can be fixed in
-  // these module maps, the clang builtin headers need to join the "system"
-  // modules (SwiftLibc). i.e. when the clang builtin stdint.h is in the
-  // SwiftLibc module too, the cycle goes away. Note that
-  // -fbuiltin-headers-in-system-modules does nothing to fix the same problem
-  // with C++ headers, and is generally fragile.
-  result.requiresBuiltinHeadersInSystemModules = !libcFileMapping.empty();
 
   if (ctx.LangOpts.EnableCXXInterop)
     getLibStdCxxFileMapping(result, ctx, vfs);

lib/Driver/UnixToolChains.cpp

@@ -127,7 +127,9 @@ bool isAmazonLinux2023Host() {
     }
 
 std::string toolchains::GenericUnix::getDefaultLinker() const {
-  if (getTriple().isAndroid() || isAmazonLinux2023Host())
+  if (getTriple().isAndroid() || isAmazonLinux2023Host()
+      || (getTriple().isMusl()
+          && getTriple().getVendor() == llvm::Triple::Swift))
     return "lld";
 
   switch (getTriple().getArch()) {
@@ -285,7 +287,8 @@ toolchains::GenericUnix::constructInvocation(const DynamicLinkJobAction &job,
   }
 
   SmallString<128> SharedResourceDirPath;
-  getResourceDirPath(SharedResourceDirPath, context.Args, /*Shared=*/true);
+  getResourceDirPath(SharedResourceDirPath, context.Args,
+                     /*Shared=*/!(staticExecutable || staticStdlib));
 
   SmallString<128> swiftrtPath = SharedResourceDirPath;
   llvm::sys::path::append(swiftrtPath,