Have the frontend and new swift-driver look in an external `-sdk` for non-Darwin platform runtime libraries and modules too #79621

finagolfin · 2025-02-25T23:16:19Z

as done originally in #25990 with the legacy C++ Driver, but since lost in the new swift-driver

This is another attempt to fix swiftlang/swift-driver#1562 and avoid the various workarounds that have been put in elsewhere to spackle over this root cause.

This worked for me with the compiler validation suite running natively on an Android device, with the exception of one SourceKit test. Let's run it through all the platforms on the CI before explaining fully what it's doing and adding a test to make sure it doesn't regress.

finagolfin · 2025-02-25T23:16:49Z

@swift-ci please test

finagolfin · 2025-02-26T14:08:31Z

swiftlang/swift-driver#1822
@swift-ci please test linux

finagolfin · 2025-02-27T04:41:28Z

swiftlang/swift-driver#1822
@swift-ci please test linux

finagolfin · 2025-02-27T05:20:55Z

lib/Frontend/CompilerInvocation.cpp

+        FrontendOpts.UseSharedResourceFolder ? "swift" : "swift_static",
+        getPlatformNameForTriple(Triple));
+    // Check for eg <sdkRoot>/usr/lib/swift/linux/
+    if (llvm::sys::fs::exists(SDKResourcePath)) {


I initially tried simply checking if <sdkRoot>/usr/lib/swift/, ie a Swift resource directory, existed, but around 100 tests from the compiler validation suite failed with that, as they pass in a separate -sdk that simply has a Swift resource directory with a few different API notes or something, but does not contain the platform-specific files needed in <sdkRoot>/usr/lib/swift/<os>/. Actually checking for this OS-specific directory makes sure the Swift resource directory in -sdk contains the required platform-specific modules and libraries, and falls back to the Swift resource directory in the toolchain itself otherwise. However, that implies mixing and matching files from two different Swift resource directories, so maybe it will be better to enforce that only one Swift resource directory is used and modify all those tests instead?

For an example of such mixing already taking place, the Windows CI failed with this pull, right before trying to compile the trunk Foundation macros for the Windows host:

-- Check for working Swift compiler: T:/5/bin/swiftc.exe - broken CMake Error at C:/Program Files/CMake/share/cmake-3.29/Modules/CMakeTestSwiftCompiler.cmake:40 (message): The Swift compiler "T:/5/bin/swiftc.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: 'T:/x86_64-unknown-windows-msvc/FoundationMacros/CMakeFiles/CMakeScratch/TryCompile-6u6j6e' Run Build Command(s): C:/PROGRA~1/MICROS~2/2022/COMMUN~1/Common7/IDE/COMMON~1/MICROS~1/CMake/Ninja/ninja.exe -v cmTC_bc87d [1/2][ 50%][0.084s] T:\5\bin\swiftc.exe -target x86_64-unknown-windows-msvc -j 36 -num-threads 36 -c -module-name cmTC_bc87d -sdk T:/toolchains/swift-6.0.3-RELEASE-windows10/LocalApp/Programs/Swift/Platforms/6.0.3/Windows.platform/Developer/SDKs/Windows.sdk -gnone -Xlinker /INCREMENTAL:NO -Xlinker /OPT:REF -Xlinker /OPT:ICF -incremental -output-file-map CMakeFiles\cmTC_bc87d.dir\\output-file-map.json T:\x86_64-unknown-windows-msvc\FoundationMacros\CMakeFiles\CMakeScratch\TryCompile-6u6j6e\main.swift FAILED: CMakeFiles/cmTC_bc87d.dir/main.swift.obj T:\5\bin\swiftc.exe -target x86_64-unknown-windows-msvc -j 36 -num-threads 36 -c -module-name cmTC_bc87d -sdk T:/toolchains/swift-6.0.3-RELEASE-windows10/LocalApp/Programs/Swift/Platforms/6.0.3/Windows.platform/Developer/SDKs/Windows.sdk -gnone -Xlinker /INCREMENTAL:NO -Xlinker /OPT:REF -Xlinker /OPT:ICF -incremental -output-file-map CMakeFiles\cmTC_bc87d.dir\\output-file-map.json T:\x86_64-unknown-windows-msvc\FoundationMacros\CMakeFiles\CMakeScratch\TryCompile-6u6j6e\main.swift <unknown>:0: warning: using (deprecated) legacy driver, Swift installation does not contain swift-driver at: 'C:\Users\swift-ci\jenkins\workspace\swift-PR-windows\build\5\bin\swift-driver-new.exe' <unknown>:0: warning: option '-incremental' is only supported in swift-driver <unknown>:0: error: module compiled with Swift 6.0.3 cannot be imported by the Swift 6.2 compiler: T:/toolchains/swift-6.0.3-RELEASE-windows10/LocalApp/Programs/Swift/Platforms/6.0.3/Windows.platform/Developer/SDKs/Windows.sdk\usr\lib\swift\windows\Swift.swiftmodule\x86_64-unknown-windows-msvc.swiftmodule ninja: build stopped: subcommand failed.

The issue appears to be that they're trying to build the trunk Foundation macros with the freshly-built trunk 6.2 Swift compiler, but passing in a Swift 6.0.3 SDK with -sdk T:/toolchains/swift-6.0.3-RELEASE-windows10/LocalApp/Programs/Swift/Platforms/6.0.3/Windows.platform/Developer/SDKs/Windows.sdk to build it. The trunk Swift 6.2 compiler then quietly ignores that 6.0.3 Swift resource directory and likely uses the 6.2 Swift resource directory next to the toolchain instead. This pull, by enforcing that the Swift resource directory in the 6.0.3 -sdk that is passed in is used because <6.0.3-sdkRoot>/usr/lib/swift/windows/ exists, then fails because the 6.0.3 modules cannot be used with the trunk Swift 6.2 compiler.

@weliveindetail, do you know if that's merely a configuration mistake when building the Foundation and Testing macros on the Windows CI, which should be easily fixed, or something more complicated?

finagolfin · 2025-02-27T09:30:37Z

lib/Frontend/CompilerInvocation.cpp


  if (const Arg *A = Args.getLastArg(OPT_resource_dir))
    Opts.RuntimeResourcePath = A->getValue();
+  else if (!Triple.isOSDarwin() && Args.hasArg(OPT_sdk)) {


This code explicitly follows what the original C++ Driver has long done when looking for the Swift runtime libraries, swiftrt.o, and a few other files found in the Swift resource directory:

if (const Arg *A = args.getLastArg(options::OPT_resource_dir)) { StringRef value = A->getValue(); resourceDirPath.append(value.begin(), value.end()); } else if (!getTriple().isOSDarwin() && args.hasArg(options::OPT_sdk)) { StringRef value = args.getLastArg(options::OPT_sdk)->getValue(); resourceDirPath.append(value.begin(), value.end()); llvm::sys::path::append(resourceDirPath, "usr"); CompilerInvocation::appendSwiftLibDir(resourceDirPath, shared); } else { auto programPath = getDriver().getSwiftProgramPath(); CompilerInvocation::computeRuntimeResourcePathFromExecutablePath( programPath, shared, resourceDirPath); }

Note how the SDK is only looked in if a non-Darwin -sdk is explicitly specified: Saleem later tried to expand that to Darwin also in #26361, but he may have never got it to work.

That C++ Driver setup now matches this Frontend setup, because the default in both is now to look relative to the compiler, which is done first in this Frontend here, ie usr/bin/../lib/swift/. If a -resource-dir is set, that is given first priority, then a non-Darwin -sdk is given second priority, ie the C++ Driver and the Frontend now match in where they look.

This is important for two reasons:

The new swift-driver simply queries the Frontend and uses whatever Swift resource directory it uses, so now the new swift-driver finally matches the original C++ Driver's behavior, and piecemeal workarounds like that in [Unix] Go back to only checking the runtime resource path for swiftrt.o swift-driver#1822 can now be eliminated.

The Frontend will now look in the same Swift resource directory for stdlib/corelibs swiftmodules as the swift-driver is looking for runtime libraries and swiftrt.o, eliminating any confusion between the two by centralizing the Swift resource directory lookup here. That already found one bug in the Windows CI, see my other code comment.

However, unlike the C++ Driver, my -sdk code below actually checks if the -sdk path contains a Swift resource directory for the platform triple and does not use the -sdk for this if not, falling back to the aforementioned default next to the compiler in that case. This is because an -sdk is not guaranteed to have a Swift resource directory and may have only a C/C++ sysroot.

We should probably tighten this up to require an explicit -sdk to have a Swift resource directory, with the only exception when an explicit -resource-dir is also specified, but I'm open to debate here. The C++ Driver doesn't even check if the non-Darwin -sdk has a Swift resource directory and simply assumes one is there, we can do a bit better than that.

finagolfin · 2025-02-27T09:44:16Z

Alright, this tiny pull and the resulting swiftlang/swift-driver#1822 cleanup now pass the linux CI, have no effect on Darwin, and found a seeming bug in the Windows CI. I'm going to test this more in comparison to the C++ Driver and examine more tests to see if I can use it to flush out more cross-compilation bugs with an explicit non-Darwin -sdk.

In the meantime, the basic functionality works and is ready for review. I will add tests once the few remaining smaller design choices mentioned above are hammered out.

@artemcm, @etcwilde, and @compnerd, please take a look: I'm looking for feedback on both this current patch and the remaining issues and questions in my detailed comments above.

finagolfin · 2025-03-08T12:32:27Z

swiftlang/swift-driver#1827
@swift-ci please build toolchain

finagolfin · 2025-03-08T15:54:44Z

swiftlang/swift-driver#1827
@swift-ci please test source compatibility

finagolfin · 2025-09-07T12:33:41Z

swiftlang/swift-corelibs-libdispatch#892
swiftlang/swift-driver#1822
swiftlang/swift-foundation#1465
swiftlang/swift-testing#1260

@swift-ci smoke test windows

finagolfin · 2025-09-08T19:03:38Z

swiftlang/swift-corelibs-libdispatch#892
swiftlang/swift-driver#1822
swiftlang/swift-foundation#1465
swiftlang/swift-testing#1260

@swift-ci smoke test windows

finagolfin · 2025-09-10T18:54:41Z

swiftlang/swift-corelibs-libdispatch#892
swiftlang/swift-driver#1822
swiftlang/swift-foundation#1465
swiftlang/swift-testing#1260

@swift-ci smoke test

finagolfin · 2025-09-11T18:12:11Z

Check if Windows install error is spurious.

swiftlang/swift-corelibs-libdispatch#892
swiftlang/swift-driver#1822
swiftlang/swift-foundation#1465
swiftlang/swift-testing#1260

@swift-ci smoke test windows

compnerd · 2025-09-11T21:12:19Z

include/swift/AST/DiagnosticsFrontend.def

+WARNING(warning_no_resource_dir_in_sdk, none,
+        "You passed in an external -sdk without a Swift runtime.\n"
+        "    Either specify a directory containing the runtime libraries with\n"
+        "    the -resource-dir flag, or use -sysroot instead to point at a C/C++\n"
+        "    sysroot alone. Falling back to this path for the Swift runtime modules\n"
+        "    and libraries:\n"
+        "    %0", (StringRef))


This feels wrong. I don't think that we should be trying to format with indentation here. Do any other warnings try to do this?

I thought it read better, but had not finalized it yet. I will look at the other warnings next and match them.

compnerd · 2025-09-11T21:12:47Z

lib/ClangImporter/ClangImporter.cpp

-  // Prefer `-sdk` paths.
-  if (!searchPathOpts.getSDKPath().empty()) {
+  // Prefer `-sdk` paths for Darwin.
+  if (triple.isOSDarwin() && !searchPathOpts.getSDKPath().empty()) {


Wait, why are we not preferring -sdk paths?

Once the Frontend change is made for non-Darwin, the RuntimeResourcePath in the very next block has been set to <-sdk>/usr/lib/swift, so this explicit getSDKPath() check is not needed when targeting non-Darwin. 😺

compnerd · 2025-09-11T21:16:19Z

utils/build.ps1

          $SwiftFlags += @("-Xlinker", "/INCREMENTAL:NO")
          # Swift requires COMDAT folding and de-duplication
-          $SwiftFlags += @("-Xlinker", "/OPT:REF", "-Xlinker", "/OPT:ICF")
+          $SwiftFlags += @("-Xlinker", "/OPT:REF", "-Xlinker", "/OPT:ICF", "-v")


Please revert htis change

compnerd · 2025-09-11T21:16:29Z

utils/build.ps1

      ENABLE_SWIFT = "YES";
      dispatch_INSTALL_ARCH_SUBDIR = "YES";
-    }
+      BUILT_FIRST_SDK = if ($Platform -eq $KnownPlatforms["WindowsX64"]) { "NO" } else { "YES" };


What does "first sdk" mean?

I was planning to change this to USE_PREBUILT_SDK or something like that, name suggestion welcome.

compnerd · 2025-09-11T21:16:36Z

utils/build.ps1

      _SwiftFoundationICU_SourceDIR = "$SourceCache\swift-foundation-icu";
      _SwiftCollections_SourceDIR = "$SourceCache\swift-collections";
      SwiftFoundation_MACRO = "$(Get-ProjectBinaryCache $BuildPlatform BootstrapFoundationMacros)\bin"
+      BUILT_FIRST_SDK = if ($Platform -eq $KnownPlatforms["WindowsX64"]) { "NO" } else { "YES" };


compnerd · 2025-09-11T21:17:34Z

utils/build.ps1

      SwiftTesting_INSTALL_NESTED_SUBDIR = "YES";
+      CMAKE_Swift_FLAGS = @(
+        "-L$(Get-SwiftSDK $Platform.OS)\usr\lib\swift\$($Platform.OS.ToString())"
+      );


Please retain the lexicographical ordering

compnerd · 2025-09-11T21:17:41Z

utils/build.ps1

    "-Xswiftc", "-I$SourceCache\sourcekit-lsp\Sources\CCompletionScoring\include",
    "-Xswiftc", "-I$(Get-ProjectBinaryCache $BuildPlatform SourceKitLSP)\swift",
-    "-Xlinker", "-L$(Get-ProjectBinaryCache $BuildPlatform SourceKitLSP)\lib"
+    "-Xlinker", "-L$(Get-ProjectBinaryCache $BuildPlatform SourceKitLSP)\lib", "-v"


Please drop this change

compnerd · 2025-09-11T21:17:52Z

utils/build.ps1

  if ($Test -contains "swiftpm") { Invoke-BuildStep Test-PackageManager $BuildPlatform }
  if ($Test -contains "swift-format") { Invoke-BuildStep Test-Format $BuildPlatform }
-  if ($Test -contains "sourcekit-lsp") { Invoke-BuildStep Test-SourceKitLSP $BuildPlatform}
+  # if ($Test -contains "sourcekit-lsp") { Invoke-BuildStep Test-SourceKitLSP $BuildPlatform}


Please restore this change

finagolfin · 2025-09-12T08:34:47Z

@compnerd, thanks for the review, but I am mainly looking for feedback on the two actual compiler changes, one of which you commented on, and the tests right now. This is still a WIP for the build.ps1 Powershell script, as you can see I had to disable the XCTest and Sourcekit-LSP tests for it to pass the Windows CI, so I'm still iterating on that Powershell script alone, hence the nits you found there, which I completely agree with. 👍

Since I've never built Swift for Windows and don't use Windows at all, I think I will need help from you or @Steelskin to debug and fix those last two issues on the Windows CI. Specifically,

Running check-xctest to test XCTest fails with a cryptic error that it can't find an unnamed file
Building the Sourcekit-LSP tests fails with an error that it can't find some Collections modules

Do you or Fabrice have any idea what's going on there? If one of you can try this out locally and debug those two failures, it would be very helpful, as I simply could not get XCTest to dump any useful info on the Windows CI with all the debug methods I tried in swiftlang/swift-corelibs-xctest#512.

finagolfin · 2025-09-12T19:15:09Z

swiftlang/swift-corelibs-libdispatch#892
swiftlang/swift-driver#1822
swiftlang/swift-foundation#1465
swiftlang/swift-testing#1260

@swift-ci smoke test

finagolfin · 2025-09-14T13:35:24Z

swiftlang/swift-corelibs-libdispatch#892
swiftlang/swift-corelibs-xctest#514
swiftlang/swift-driver#1822
swiftlang/swift-foundation#1465
swiftlang/swift-testing#1260

@swift-ci smoke test windows

finagolfin · 2025-09-17T19:58:05Z

Check that everything is still working well, ie only the two Windows CI issues remain.

swiftlang/swift-corelibs-libdispatch#892
swiftlang/swift-driver#1822
swiftlang/swift-foundation#1465
swiftlang/swift-testing#1260

@swift-ci test

finagolfin · 2025-09-23T22:12:46Z

Check if #84425 fixed any Windows CI issues and that the linux/mac CI remain green.

swiftlang/swift-corelibs-libdispatch#892
swiftlang/swift-driver#1822
swiftlang/swift-foundation#1465
swiftlang/swift-testing#1260

@swift-ci test

finagolfin · 2025-09-24T21:55:05Z

Alright, the XCTest issue mentioned above was just fixed by Saleem's linked pull, only the build error with the sourcekit-lsp tests remains:

unknown>:0: error: missing required modules: 'DequeModule', 'OrderedCollections', 'OrderedCollections'

error: fatalError
Error: Error: swift exited with code 1.

@compnerd or @Steelskin, any idea what's going wrong there?

finagolfin · 2025-09-26T08:49:11Z

Check if the associated Foundation and Testing pulls I have been applying above are still needed for the Windows CI.

swiftlang/swift-corelibs-libdispatch#892
swiftlang/swift-driver#1822

@swift-ci test windows

finagolfin · 2025-09-26T12:04:41Z

Check if the Testing pull is no longer needed on the Windows CI.

swiftlang/swift-corelibs-libdispatch#892
swiftlang/swift-driver#1822
swiftlang/swift-foundation#1465

@swift-ci test windows

finagolfin · 2025-09-29T11:12:07Z

Check latest CI results:

swiftlang/swift-corelibs-libdispatch#892
swiftlang/swift-driver#1822
swiftlang/swift-foundation#1465

@swift-ci test

finagolfin · 2025-09-30T17:39:23Z

swiftlang/swift-corelibs-libdispatch#892
swiftlang/swift-driver#1822
swiftlang/swift-foundation#1465

@swift-ci test

… non-Darwin platform runtime libraries and modules too as done originally in swiftlang#25990 with the legacy C++ Driver, but since lost in the new swift-driver. Only difference is this checks if a Swift resource directory exists in `-sdk` and falls back to the default if not.

finagolfin · 2025-10-01T09:30:54Z

Try collections fix for testing Sourcekit-LSP on Windows:

swiftlang/swift-corelibs-libdispatch#892
swiftlang/swift-driver#1822
swiftlang/swift-foundation#1465

@swift-ci test windows

finagolfin · 2025-10-01T16:16:38Z

utils/build.ps1

    "-Xlinker", "$(Get-ProjectBinaryCache $BuildPlatform Crypto)\lib\libCCryptoBoringSSL.lib",
+    # swift-collections
+    "-Xswiftc", "-I$(Get-ProjectBinaryCache $BuildPlatform Collections)\swift",
+    "-Xlinker", "-L$(Get-ProjectBinaryCache $BuildPlatform Collections)\lib",


@compnerd, these two lines finally got the Windows CI to pass. It appears the issue is that the build of the sourcekit-lsp tests was inadvertently importing the Collections modules next to the Swift compiler, ie in usr\bin\..\lib\swift\windows\, but this pull finally forced the compiler to only look in the -sdk path, plus any extra command-line flags passed in. Once I added Swift Collections to this list of command-line flags, the sourcekit-lsp tests passed again.

I took a look at the installed files in the resource directory next to the Windows Swift compiler and got this list:

> ag "Installing.*Files/Swift/Toolchains/0.0.0\+Asserts/usr/lib/swift/windows/" windows.log 12869:[2025-09-19T03:44:23.923Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/_InternalSwiftStaticMirror.lib 12949:[2025-09-19T03:45:02.033Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/_InternalSwiftScan.lib 149318:[2025-09-19T08:45:29.782Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/ArgumentParser.lib 149320:[2025-09-19T08:45:29.782Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/x86_64/ArgumentParser.swiftdoc 149321:[2025-09-19T08:45:29.782Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/x86_64/ArgumentParser.swiftmodule 149927:[2025-09-19T08:48:12.805Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/Collections.swiftmodule/x86_64-unknown-windows-msvc.swiftdoc 149928:[2025-09-19T08:48:12.805Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/Collections.swiftmodule/x86_64-unknown-windows-msvc.swiftmodule 149929:[2025-09-19T08:48:12.805Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/BitCollections.lib 149931:[2025-09-19T08:48:13.062Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/BitCollections.swiftmodule/x86_64-unknown-windows-msvc.swiftdoc 149932:[2025-09-19T08:48:13.062Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/BitCollections.swiftmodule/x86_64-unknown-windows-msvc.swiftmodule 149933:[2025-09-19T08:48:13.062Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/HashTreeCollections.lib 149935:[2025-09-19T08:48:13.062Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/HashTreeCollections.swiftmodule/x86_64-unknown-windows-msvc.swiftdoc 149936:[2025-09-19T08:48:13.062Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/HashTreeCollections.swiftmodule/x86_64-unknown-windows-msvc.swiftmodule 149937:[2025-09-19T08:48:13.062Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/HeapModule.lib 149939:[2025-09-19T08:48:13.062Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/HeapModule.swiftmodule/x86_64-unknown-windows-msvc.swiftdoc 149940:[2025-09-19T08:48:13.062Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/HeapModule.swiftmodule/x86_64-unknown-windows-msvc.swiftmodule 149941:[2025-09-19T08:48:13.062Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/DequeModule.lib 149943:[2025-09-19T08:48:13.322Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/DequeModule.swiftmodule/x86_64-unknown-windows-msvc.swiftdoc 149944:[2025-09-19T08:48:13.322Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/DequeModule.swiftmodule/x86_64-unknown-windows-msvc.swiftmodule 149945:[2025-09-19T08:48:13.322Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/OrderedCollections.lib 149947:[2025-09-19T08:48:13.322Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/OrderedCollections.swiftmodule/x86_64-unknown-windows-msvc.swiftdoc 149948:[2025-09-19T08:48:13.322Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/OrderedCollections.swiftmodule/x86_64-unknown-windows-msvc.swiftmodule 149949:[2025-09-19T08:48:13.322Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/_RopeModule.lib 149951:[2025-09-19T08:48:13.322Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/_RopeModule.swiftmodule/x86_64-unknown-windows-msvc.swiftdoc 149952:[2025-09-19T08:48:13.322Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/_RopeModule.swiftmodule/x86_64-unknown-windows-msvc.swiftmodule 149953:[2025-09-19T08:48:13.322Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/InternalCollectionsUtilities.lib 149955:[2025-09-19T08:48:13.322Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/InternalCollectionsUtilities.swiftmodule/x86_64-unknown-windows-msvc.swiftdoc 149956:[2025-09-19T08:48:13.322Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/InternalCollectionsUtilities.swiftmodule/x86_64-unknown-windows-msvc.swiftmodule 161994:[2025-09-19T08:55:56.838Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/SwiftFormat.lib 161996:[2025-09-19T08:55:56.838Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/x86_64/SwiftFormat.swiftdoc 161997:[2025-09-19T08:55:56.838Z] -- Installing: T:/Program Files/Swift/Toolchains/0.0.0+Asserts/usr/lib/swift/windows/x86_64/SwiftFormat.swiftmodule

Should these modules be there? Maybe you remove them later in the build, but it seems like you're trying to move all these Swift modules to the SDK directories instead, except for the _Internal and Format host toolchain libraries.

Let me know if this CLI flag addition above is okay. I will clean up this pull next, run it through the CI a final time, then it should be ready for review.

finagolfin requested review from artemcm and tshortli as code owners February 25, 2025 23:16

finagolfin marked this pull request as draft February 25, 2025 23:21

finagolfin mentioned this pull request Feb 26, 2025

[Unix] Go back to only checking the runtime resource path for swiftrt.o swiftlang/swift-driver#1822

Open

finagolfin commented Feb 27, 2025

View reviewed changes

finagolfin mentioned this pull request Feb 27, 2025

Problems with the planned new cross-compilation model #79657

Open

finagolfin commented Feb 27, 2025

View reviewed changes

finagolfin marked this pull request as ready for review February 27, 2025 09:44

finagolfin force-pushed the sdk branch from 630545f to 32f01c9 Compare March 10, 2025 16:36

finagolfin requested review from zoecarver, hyp, egorzhdan, beccadax, ian-twilightcoder, Xazax-hun, j-hui and fahadnayyar as code owners March 10, 2025 16:36

finagolfin marked this pull request as draft March 10, 2025 16:42

finagolfin removed request for hyp, Xazax-hun, egorzhdan, zoecarver, ian-twilightcoder and fahadnayyar March 10, 2025 16:43

finagolfin force-pushed the sdk branch from f129f0e to b4104d8 Compare September 8, 2025 19:02

finagolfin force-pushed the sdk branch from b4104d8 to 9f51fb9 Compare September 10, 2025 18:42

compnerd requested changes Sep 11, 2025

View reviewed changes

finagolfin force-pushed the sdk branch from 9f51fb9 to 0a3b7bc Compare September 12, 2025 19:12

finagolfin force-pushed the sdk branch from 0a3b7bc to 01635dc Compare September 14, 2025 13:25

finagolfin force-pushed the sdk branch from 01635dc to 748bc36 Compare September 17, 2025 19:56

finagolfin force-pushed the sdk branch from 748bc36 to 791e5e5 Compare September 23, 2025 22:08

finagolfin force-pushed the sdk branch 2 times, most recently from 0297f90 to 77817fa Compare September 26, 2025 08:45

finagolfin force-pushed the sdk branch from 77817fa to fe9fcc5 Compare September 26, 2025 12:02

finagolfin force-pushed the sdk branch from fe9fcc5 to bc48b77 Compare September 29, 2025 11:10

finagolfin force-pushed the sdk branch from bc48b77 to 9c2da51 Compare September 30, 2025 17:36

finagolfin force-pushed the sdk branch from 9c2da51 to 0a98b27 Compare October 1, 2025 09:29

finagolfin commented Oct 1, 2025

View reviewed changes

Have the frontend and new swift-driver look in an external -sdk for non-Darwin platform runtime libraries and modules too #79621

Are you sure you want to change the base?

Have the frontend and new swift-driver look in an external -sdk for non-Darwin platform runtime libraries and modules too #79621

Conversation

finagolfin commented Feb 25, 2025

Uh oh!

finagolfin commented Feb 25, 2025

Uh oh!

finagolfin commented Feb 26, 2025

Uh oh!

finagolfin commented Feb 27, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

finagolfin commented Feb 27, 2025

Uh oh!

finagolfin commented Mar 8, 2025

Uh oh!

finagolfin commented Mar 8, 2025

Uh oh!

finagolfin commented Sep 7, 2025

Uh oh!

finagolfin commented Sep 8, 2025

Uh oh!

finagolfin commented Sep 10, 2025

Uh oh!

finagolfin commented Sep 11, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

finagolfin commented Sep 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

finagolfin commented Sep 12, 2025

Uh oh!

finagolfin commented Sep 14, 2025

Uh oh!

finagolfin commented Sep 17, 2025

Uh oh!

finagolfin commented Sep 23, 2025

Uh oh!

finagolfin commented Sep 24, 2025

Uh oh!

finagolfin commented Sep 26, 2025

Uh oh!

finagolfin commented Sep 26, 2025

Uh oh!

finagolfin commented Sep 29, 2025

Uh oh!

finagolfin commented Sep 30, 2025

Uh oh!

finagolfin commented Oct 1, 2025

Have the frontend and new swift-driver look in an external `-sdk` for non-Darwin platform runtime libraries and modules too #79621

Have the frontend and new swift-driver look in an external `-sdk` for non-Darwin platform runtime libraries and modules too #79621

finagolfin commented Sep 12, 2025 •

edited

Loading