swiftlang / swift-driver Goto Github PK
View Code? Open in Web Editor NEWSwift compiler driver reimplementation in Swift
License: Apache License 2.0
Swift compiler driver reimplementation in Swift
License: Apache License 2.0
I’ve recently made a Swift program several times faster by changing one class into a struct. Here is the class version.
Judging from the CPU profile gathered by Instruments.app, the slow down prior to the change was mostly caused by release&retain calls:
Those calls all but disappeared from the profile after changing the Sudoku
class into a struct. The timings:
class:
$ time ./sudoku >/dev/null
./sudoku > /dev/null 9.72s user 0.03s system 99% cpu 9.771 total
struct:
$ time ./sudoku >/dev/null
./sudoku > /dev/null 1.81s user 0.00s system 99% cpu 1.815 total
The command I used to compile the program:
swiftc -Ounchecked sudoku.swift
What’s surprising is that if I create a new CLI app project in XCode, paste the same source code (with the class version of the code) into main.swift
and build the project in Release mode, then its timing becomes:
$ time ./Sudoku >/dev/null
./Sudoku > /dev/null 2.86s user 0.01s system 99% cpu 2.874 total
That’s a lot faster than the version compiled with the swiftc
command. If I compile the struct version with -O
instead of -Ounchecked
(because XCode in Release mode uses -O
), then it turns out that the struct version compiled with swiftc
is not much faster than the class version compiled with XCode:
$ time ./sudoku >/dev/null
./sudoku > /dev/null 2.47s user 0.01s system 99% cpu 2.481 total
The difference in the number of retain&release calls can also be observed by running DTrace against the struct and class versions:
First save the class
version of this code in sudoku-class.swift
, the struct
version in sudoku-struct.swift
and the final class
version in sudoku-final-class.swift
. Then:
sudo -v # just to refresh the sudo password before the next command
for ver in sudoku-struct sudoku-class sudoku-final-class; do echo -e "\n=========\nVERSION: $ver\n=========\n"; swiftc -Ounchecked "$ver.swift"; time sudo dtrace -c "./$ver" -n 'pid$target:libswiftCore.dylib:swift_retain:entry { @[probefunc] = count(); } profile:::tick-60s { printf("\nTIMEOUT\n"); exit(0); }'; done
Results:
=========
VERSION: sudoku-struct
=========
dtrace: system integrity protection is on, some features will not be available
dtrace: description 'pid$target:libswiftCore.dylib:swift_retain:entry ' matched 2 probes
done
4000
dtrace: pid 67148 has exited
swift_retain 292003
sudo dtrace -c "./$ver" -n 1.96s user 0.79s system 97% cpu 2.829 total
=========
VERSION: sudoku-class
=========
dtrace: system integrity protection is on, some features will not be available
dtrace: description 'pid$target:libswiftCore.dylib:swift_retain:entry ' matched 2 probes
CPU ID FUNCTION:NAME
4 6248 :tick-60s
TIMEOUT
swift_retain 21329236
sudo dtrace -c "./$ver" -n 5.58s user 54.57s system 99% cpu 1:00.22 total
=========
VERSION: sudoku-final-class
=========
dtrace: system integrity protection is on, some features will not be available
dtrace: description 'pid$target:libswiftCore.dylib:swift_retain:entry ' matched 2 probes
done
4000
dtrace: pid 67162 has exited
swift_retain 288003
sudo dtrace -c "./$ver" -n 2.30s user 0.78s system 90% cpu 3.404 total
The struct version made 292003 calls to swift_retain
and successfully finished in under 3 seconds. The final class
version made 288003 calls and successfully finished in ~3.5 seconds. The non-final class version made a whopping 21329236 calls to swift_retain
and the DTrace script terminated the program after a full minute timeout. Without the timeout, this version is happy to run for 20 minutes or more when swift_retain
is instrumented by DTrace (kinda to be expected, when the instrumented function is called so many times).
Now let’s look at the class version compiled with XCode:
time sudo dtrace -c ./Sudoku -n 'pid$target:libswiftCore.dylib:swift_retain:entry { @[probefunc] = count(); } profile:::tick-60s { printf("\nTIMEOUT\n"); exit(0); }'
dtrace: system integrity protection is on, some features will not be available
dtrace: description 'pid$target:libswiftCore.dylib:swift_retain:entry ' matched 2 probes
done
4000
dtrace: pid 67175 has exited
swift_retain 288003
sudo dtrace -c ./Sudoku -n 3.00s user 0.79s system 99% cpu 3.801 total
288003 calls to swift_retain
and successful exit after 3.8 seconds. Hmm... Those numbers seem awfully similar to the final class
version compiled with swiftc
. The numer of calls to swift_retain
matches exactly.
So I suspect that the Swift compiler invoked by XCode noticed that the class is final
even without the help of an annotation and somehow used it to optimise away a load of retain&release calls, while bare swiftc
failed to do so.
I’ve tried looking at the XCode build log to check the flags passed to the compiler, but XCode uses swift-frontend
instead of swiftc
and many of the flags there are invalid for swiftc
. The ones that I tried which worked didn’t make a difference.
swiftc
version:
$ swiftc --version
swift-driver version: 1.87.3 Apple Swift version 5.9.2 (swiftlang-5.9.2.2.56 clang-1500.1.0.2.5)
Target: arm64-apple-macosx13.0
XCode version: 15.1
Hi all. Currently I am working on a big Swift/Objc project. When using old swift driver (Via -disallow-use-new-driver
option) the performance is great, but when I switch to new-swift-driver compilation is stuck on every large swift module. Time taken by swift-driver to analyze dependencies can be longer than actual time to compile the whole module. The largest module has about 700 sources and contains 182 imports (Counted by -emit-imported-modules
), half of them are Objc modules.
After some research I figured out that disabling emitting dependsExternal section to swiftdeps file slightly increaces driver speed. Maybe it will help somehow.
I am looking for a patch or some architecture solution (For example isolating all Objc modules with @_implementationOnly imports) and will be happy with any help.
we decided to update macOS and XCode to lunching our react-native app on new version softwares although it had some weird errors, ran and built success. we ignored them at that time but when we wanted to get an archive those error presented and made archiving failed.
there tow type of error
Dependency for P1:target-app- 69a90293829c4577a609157fb85f5e0d7ceb6b36bcfc2fb90f69ac96de4975d6-:Debug:SwiftDriver Compilation Requirements app normal arm64 com.apple.xcode.tools.swift.compiler is not absolute (Pods/TensorFlowLiteC/Frameworks/TensorFlowLiteC.framework/Modules/module.modulemap).
Dependency for P1:target-app- 69a90293829c4577a609157fb85f5e0d7ceb6b36bcfc2fb90f69ac96de4975d6-:Debug:SwiftDriver Compilation Requirements app normal arm64 com.apple.xcode.tools.swift.compiler is not absolute (Pods/TensorFlowLiteC/Frameworks/TensorFlowLiteC.framework/Modules/module.modulemap).
we faced with this error with :
XCode | 14.1
react-native | 69.3
TensorFlowLiteSwift | 2.3.0
TensorFlowLiteSwift | 2.3.0
cocoapods | 11.12.1
PromisesObjC | 1.2.12
macOs | 13.4
ruby | 2.63 (tested 2.7.4)
on apple macmini intel
**we try to solve it by solutions below: **
we stuck in it
please help us
Building a binary for -target armv7em-none-none-eabi
with -o
and -emit-module
works if -g
is not specified.
Works:
➜ Desktop xcrun --toolchain org.swift.59202403131a swiftc -target armv7em-none-none-eabi -c foo.swift -o foo.o -emit-module -wmo -enable-experimental-feature Embedded
Fails:
➜ Desktop xcrun --toolchain org.swift.59202403131a swiftc -target armv7em-none-none-eabi -c foo.swift -o foo.o -emit-module -wmo -enable-experimental-feature Embedded -g
SwiftDriverExecution/MultiJobExecutor.swift:207: Fatal error: multiple producers for output foo.o: Wrapping Swift module foo & Compiling foo foo.swift
[1] 85772 trace trap xcrun --toolchain org.swift.59202403131a swiftc -target armv7em-none-none-eab
Failing Frontend commands:
/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2024-03-13-a.xctoolchain/usr/bin/swift-frontend -frontend -c foo.swift -target armv7em-none-none-eabi -disable-objc-interop -sdk /Applications/XcodeGeode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.0.sdk -color-diagnostics -g -debug-info-format=dwarf -dwarf-version=4 -enable-experimental-feature Embedded -empty-abi-descriptor -resource-dir /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2024-03-13-a.xctoolchain/usr/lib/swift -enable-anonymous-context-mangled-names -file-compilation-dir /Users/rauhul/Desktop -module-name foo -plugin-path /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2024-03-13-a.xctoolchain/usr/lib/swift/host/plugins -plugin-path /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2024-03-13-a.xctoolchain/usr/local/lib/swift/host/plugins -o foo.o
/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2024-03-13-a.xctoolchain/usr/bin/swift-frontend -frontend -emit-module -experimental-skip-non-inlinable-function-bodies-without-types foo.swift -target armv7em-none-none-eabi -disable-objc-interop -sdk /Applications/XcodeGeode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.0.sdk -color-diagnostics -g -debug-info-format=dwarf -dwarf-version=4 -enable-experimental-feature Embedded -empty-abi-descriptor -resource-dir /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2024-03-13-a.xctoolchain/usr/lib/swift -enable-anonymous-context-mangled-names -file-compilation-dir /Users/rauhul/Desktop -module-name foo -plugin-path /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2024-03-13-a.xctoolchain/usr/lib/swift/host/plugins -plugin-path /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2024-03-13-a.xctoolchain/usr/local/lib/swift/host/plugins -emit-module-doc-path foo.swiftdoc -emit-module-source-info-path foo.swiftsourceinfo -o foo.swiftmodule
/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2024-03-13-a.xctoolchain/usr/bin/swift-frontend -modulewrap foo.swiftmodule -target armv7em-none-none-eabi -o foo.o
@compnerd and some Windows devs have been trying out Android cross-compilation from Windows, and in response to some issues they've been seeing, I suggested symlinking the Swift files into the C sysroot in the Android NDK. I then tried it myself on linux, using my Android SDK for Swift for convenience, and found that it works with the legacy C++ Driver, but not this one:
> wget https://github.com/finagolfin/swift-android-sdk/releases/download/5.9.2/swift-5.9.2-android-24-sdk.tar.xz
> tar xf swift-5.9.2-android-24-sdk.tar.xz
> ln -s ~/swift-5.9.2-android-24-sdk/usr/lib/swift android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/swift
> ./swift-5.9.2-RELEASE-ubi9/usr/bin/swiftc -tools-directory ~/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/bin/ -target aarch64-unknown-linux-android24 -sdk android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot swift/test/Interpreter/hello_toplevel.swift -v -L swift-5.9.2-android-24-sdk/usr/lib/aarch64-linux-android/ -disallow-use-new-driver
<unknown>:0: warning: legacy driver is now deprecated; consider avoiding specifying '-disallow-use-new-driver'
Swift version 5.9.2 (swift-5.9.2-RELEASE)
Target: aarch64-unknown-linux-android24
/home/fina/swift-5.9.2-RELEASE-ubi9/usr/bin/swift-frontend -frontend -c -primary-file swift/test/Interpreter/hello_toplevel.swift -target aarch64-unknown-linux-android24 -Xllvm -aarch64-use-tbi -disable-objc-interop -sdk android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot -color-diagnostics -tools-directory /home/fina/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/bin/ -plugin-path /home/fina/swift-5.9.2-RELEASE-ubi9/usr/lib/swift/host/plugins -plugin-path /home/fina/swift-5.9.2-RELEASE-ubi9/usr/local/lib/swift/host/plugins -module-name hello_toplevel -o /tmp/hello_toplevel-b8d1e8.o
/home/fina/swift-5.9.2-RELEASE-ubi9/usr/bin/swift-autolink-extract /tmp/hello_toplevel-b8d1e8.o -o /tmp/hello_toplevel-9c4d55.autolink
/home/fina/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -fuse-ld=lld -Xlinker -z -Xlinker nostart-stop-gc -B /home/fina/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/bin/ -pie android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/swift/android/aarch64/swiftrt.o /tmp/hello_toplevel-b8d1e8.o --sysroot android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot @/tmp/hello_toplevel-9c4d55.autolink -L android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/swift/android -lswiftCore --target=aarch64-unknown-linux-android24 -v -L swift-5.9.2-android-24-sdk/usr/lib/aarch64-linux-android/ -o hello_toplevel
Android (11349228, +pgo, +bolt, +lto, -mlgo, based on r487747e) clang version 17.0.2 (https://android.googlesource.com/toolchain/llvm-project d9f89f4d16663d5012e5c09495f3b30ece3d2362)
Target: aarch64-unknown-linux-android24
Thread model: posix
InstalledDir: /home/fina/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/bin
"/home/fina/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/bin/ld.lld" --sysroot=android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot -pie -EL --fix-cortex-a53-843419 -z now -z relro -z max-page-size=4096 --hash-style=gnu --eh-frame-hdr -m aarch64linux -dynamic-linker /system/bin/linker64 -o hello_toplevel android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/24/crtbegin_dynamic.o -Landroid-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/swift/android -Lswift-5.9.2-android-24-sdk/usr/lib/aarch64-linux-android/ -L/home/fina/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/lib/clang/17/lib/linux/aarch64 -Landroid-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/24 -Landroid-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android -Landroid-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib -z nostart-stop-gc android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/swift/android/aarch64/swiftrt.o /tmp/hello_toplevel-b8d1e8.o -lswiftSwiftOnoneSupport -lswiftCore -lswift_Concurrency -lswift_StringProcessing -lswift_RegexParser -lswiftCore /home/fina/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/lib/clang/17/lib/linux/libclang_rt.builtins-aarch64-android.a -l:libunwind.a -ldl -lc /home/fina/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/lib/clang/17/lib/linux/libclang_rt.builtins-aarch64-android.a -l:libunwind.a -ldl android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/24/crtend_android.o
> file hello_toplevel
hello_toplevel: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /system/bin/linker64, not stripped
> ./swift-5.9.2-RELEASE-ubi9/usr/bin/swiftc -tools-directory ~/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/bin/ -target aarch64-unknown-linux-android24 -sdk android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot swift/test/Interpreter/hello_toplevel.swift -v -L swift-5.9.2-android-24-sdk/usr/lib/aarch64-linux-android/
warning: Could not read SDKSettings.json for SDK at: /home/fina/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot
Swift version 5.9.2 (swift-5.9.2-RELEASE)
Target: aarch64-unknown-linux-android24
/home/fina/swift-5.9.2-RELEASE-ubi9/usr/bin/swift-frontend -frontend -c -primary-file swift/test/Interpreter/hello_toplevel.swift -target aarch64-unknown-linux-android24 -Xllvm -aarch64-use-tbi -disable-objc-interop -sdk /home/fina/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot -color-diagnostics -new-driver-path /home/fina/swift-5.9.2-RELEASE-ubi9/usr/bin/swift-driver -empty-abi-descriptor -resource-dir /home/fina/swift-5.9.2-RELEASE-ubi9/usr/lib/swift -module-name hello_toplevel -plugin-path /home/fina/swift-5.9.2-RELEASE-ubi9/usr/lib/swift/host/plugins -plugin-path /home/fina/swift-5.9.2-RELEASE-ubi9/usr/local/lib/swift/host/plugins -o /tmp/TemporaryDirectory.A4x0Xq/hello_toplevel-1.o
/home/fina/swift-5.9.2-RELEASE-ubi9/usr/bin/swift-autolink-extract /tmp/TemporaryDirectory.A4x0Xq/hello_toplevel-1.o -o /tmp/TemporaryDirectory.A4x0Xq/hello_toplevel-2.autolink
/home/fina/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -fuse-ld=lld -Xlinker -z -Xlinker nostart-stop-gc -B /home/fina/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/bin -pie /home/fina/swift-5.9.2-RELEASE-ubi9/usr/lib/swift/android/aarch64/swiftrt.o /tmp/TemporaryDirectory.A4x0Xq/hello_toplevel-1.o @/tmp/TemporaryDirectory.A4x0Xq/hello_toplevel-2.autolink --sysroot /home/fina/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot -L /home/fina/swift-5.9.2-RELEASE-ubi9/usr/lib/swift/android -lswiftCore --target=aarch64-unknown-linux-android24 -v -L swift-5.9.2-android-24-sdk/usr/lib/aarch64-linux-android -o hello_toplevel
error: link command failed with exit code 1 (use -v to see invocation)
Android (11349228, +pgo, +bolt, +lto, -mlgo, based on r487747e) clang version 17.0.2 (https://android.googlesource.com/toolchain/llvm-project d9f89f4d16663d5012e5c09495f3b30ece3d2362)
Target: aarch64-unknown-linux-android24
Thread model: posix
InstalledDir: /home/fina/android-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/bin
clang-17: error: no such file or directory: '/home/fina/swift-5.9.2-RELEASE-ubi9/usr/lib/swift/android/aarch64/swiftrt.o'
error: fatalError
Note how the old C++ driver correctly passes -Landroid-ndk-r26c/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/swift/android
to the linker, while this swift-driver incorrectly passes a non-existent -L /home/fina/swift-5.9.2-RELEASE-ubi9/usr/lib/swift/android
to the linker and strangely also -resource-dir /home/fina/swift-5.9.2-RELEASE-ubi9/usr/lib/swift
to the frontend.
At the very least, we should resolve this discrepancy between the two drivers, which was probably not noticed because nobody is distributing full Unix cross-compilation SDKs, ie a single platform SDK containing both a C/C++ sysroot and Swift libraries, not bundled with the toolchain.
The CAS changes resulted in the test suite entirely breaking on Windows.
As part of the toolchain build process on M1 mac, the build-toolchain
script runs the next 2 commands:
build-script-helper.py build
and build-script-helper.py install
swift-driver/Utilities/build-script-helper.py build --package-path /Users/azarovalex/Developer/OpenSource/swift-project/swift-driver --build-path /Users/azarovalex/Developer/OpenSource/swift-project/build/buildbot_osx/swiftdriver-macosx-arm64 --configuration release --toolchain /Users/azarovalex/Developer/OpenSource/swift-project/build/buildbot_osx/intermediate-install/macosx-arm64/Library/Developer/Toolchains/swift-LOCAL-2022-09-03-a.xctoolchain/usr --ninja-bin /Users/azarovalex/Developer/OpenSource/swift-project/build/buildbot_osx/ninja-build/ninja --cmake-bin /opt/homebrew/bin/cmake --cross-compile-hosts macosx-x86_64
swift-driver/Utilities/build-script-helper.py install --package-path /Users/azarovalex/Developer/OpenSource/swift-project/swift-driver --build-path /Users/azarovalex/Developer/OpenSource/swift-project/build/buildbot_osx/swiftdriver-macosx-arm64 --configuration release --toolchain /Users/azarovalex/Developer/OpenSource/swift-project/build/buildbot_osx/intermediate-install/macosx-arm64/Library/Developer/Toolchains/swift-LOCAL-2022-09-03-a.xctoolchain/usr --ninja-bin /Users/azarovalex/Developer/OpenSource/swift-project/build/buildbot_osx/ninja-build/ninja --cmake-bin /opt/homebrew/bin/cmake --cross-compile-hosts macosx-x86_64 --prefix /Users/azarovalex/Developer/OpenSource/swift-project/build/buildbot_osx/intermediate-install/macosx-arm64/Library/Developer/Toolchains/swift-LOCAL-2022-09-03-a.xctoolchain/usr
Both these commands contain a --cross-compile-hosts macosx-x86_64
flag, so I expect artifacts for both arm64 and x86 to be built.
The arm one builds as expected, but x86 build crashes with an error:
Undefined symbols for architecture x86_64:
"_yaml_document_end_event_initialize", referenced from:
_$s4Yams7EmitterC9serialize4nodeyAA4NodeO_tKF in libYams.a(Emitter.swift.o)
"_yaml_document_start_event_initialize", referenced from:
_$s4Yams7EmitterC9serialize4nodeyAA4NodeO_tKF in libYams.a(Emitter.swift.o)
What's interesting is that all symbols start with _yams
and running lipo -info
for other dependencies return x86_64
, only libCYaml.a
return arm64
.
Moreover, if I open dependencies/yams/build.ninja
and manually replace all occurrences of -arch arm64
with -arch x86_64
, everything builds as expected (until next cmake command overwrites everything).
Looks like there is an issue with CMakeLists somewhere, maybe even in Yams repo itself, I'll appreciate any help with this issue.
Test Case 'CachingBuildTests.testCacheBuildEndToEndBuild' started at 2023-12-14 16:42:43.920
C:\Users\abdulras\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe -frontend -scan-dependencies -target x86_64-unknown-windows-msvc -disable-objc-interop -sdk C:\Users\abdulras\AppData\Local\Programs\Swift\Platforms\0.0.0\Windows.platform\Developer\SDKs\Windows.sdk -I S:\\SourceCache\\apple\\swift-driver\\TestInputs\\ExplicitModuleBuilds\\CHeaders -I S:\\SourceCache\\apple\\swift-driver\\TestInputs\\ExplicitModuleBuilds\\Swift -module-cache-path C:\\Users\\abdulras\\AppData\\Local\\Temp\\TemporaryDirectory.wrsjbq\\ModuleCache -empty-abi-descriptor -resource-dir C:\Users\abdulras\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\lib\swift -cache-compile-job -cas-path C:\\Users\\abdulras\\AppData\\Local\\Temp\\TemporaryDirectory.wrsjbq\\cas -Rcache-compile-job -module-name testCachingBuild -plugin-path S:\SourceCache\apple\swift-driver\.build\bin -plugin-path S:\SourceCache\apple\swift-driver\.build\local\bin C:\\Users\\abdulras\\AppData\\Local\\Temp\\TemporaryDirectory.wrsjbq\\testCachingBuild.swift
<EXPR>:0: error: CachingBuildTests.testCacheBuildEndToEndBuild : threw error "libSwiftScan CAS error: OnDiskCache is disabled"
Test Case 'CachingBuildTests.testCacheBuildEndToEndBuild' failed (0.097 seconds)
Test Case 'CachingBuildTests.testCacheBuildEndToEndWithBinaryHeaderDeps' started at 2023-12-14 16:42:44.017
warning: Could not read SDKSettings.json for SDK at: C:\Users\abdulras\AppData\Local\Programs\Swift\Platforms\0.0.0\Windows.platform\Developer\SDKs\Windows.sdk
SwiftDriverTests/CachingBuildTests.swift:678: Fatal error: 'try!' expression unexpectedly raised an error: libSwiftScan dependency scan query failed
Current stack trace:
SwiftDriverTests/CachingBuildTests.swift:678: Fatal error: 'try!' expression unexpectedly raised an error: libSwiftScan dependency scan query failed
Current stack trace:
SwiftDriverTests/CachingBuildTests.swift:678: Fatal error: 'try!' expression unexpectedly raised an error: libSwiftScan dependency scan query failed
Current stack trace:
SwiftDriverTests/CachingBuildTests.swift:678: Fatal error: 'try!' expression unexpectedly raised an error: libSwiftScan dependency scan query failed
Current stack trace:
SwiftDriverTests/CachingBuildTests.swift:678: Fatal error: 'try!' expression unexpectedly raised an error: libSwiftScan dependency scan query failed
Current stack trace:
SwiftDriverTests/CachingBuildTests.swift:678: Fatal error: 'try!' expression unexpectedly raised an error: libSwiftScan dependency scan query failed
Current stack trace:
SwiftDriverTests/CachingBuildTests.swift:678: Fatal error: 'try!' expression unexpectedly raised an error: libSwiftScan dependency scan query failed
Current stack trace:
SwiftDriverTests/CachingBuildTests.swift:678: Fatal error: 'try!' expression unexpectedly raised an error: libSwiftScan dependency scan query failed
Current stack trace:
SwiftDriverTests/CachingBuildTests.swift:678: Fatal error: 'try!' expression unexpectedly raised an error: libSwiftScan dependency scan query failed
Current stack trace:
SwiftDriverTests/CachingBuildTests.swift:678: Fatal error: 'try!' expression unexpectedly raised an error: libSwiftScan dependency scan query failed
Current stack trace:
SwiftDriverTests/CachingBuildTests.swift:678: Fatal error: 'try!' expression unexpectedly raised an error: libSwiftScan dependency scan query failed
Current stack trace:
SwiftDriverTests/CachingBuildTests.swift:678: Fatal error: 'try!' expression unexpectedly raised an error: libSwiftScan dependency scan query failed
Current stack trace:
0 (null) 0x00007ffd952ee9a0 swift_stdlib_reportFatalErrorInFile + 132
Describe the bug
I've been seeing a bunch of emit-module.d files in my Swift package directories with the latest 5.7 and trunk snapshot builds. The first Apr. 12 5.7 snapshot doesn't have this problem, so building with swift build -v
then comparing to the Apr. 18 snapshot shows that both run this identical command to emit a module:
/home/butta/swift-nio/swift-5.7-DEVELOPMENT-SNAPSHOT-2022-04-18-a-ubuntu20.04/usr/bin/swiftc -module-name _NIODataStructures -incremental -emit-dependencies -emit-module -emit-module-path /home/butta/swift-nio/.build/x86_64-unknown-linux-gnu/debug/_NIODataStructures.swiftmodule -output-file-map /home/butta/swift-nio/.build/x86_64-unknown-linux-gnu/debug/_NIODataStructures.build/output-file-map.json -parse-as-library -c /home/butta/swift-nio/Sources/_NIODataStructures/Heap.swift /home/butta/swift-nio/Sources/_NIODataStructures/PriorityQueue.swift -I /home/butta/swift-nio/.build/x86_64-unknown-linux-gnu/debug -target x86_64-unknown-linux-gnu -swift-version 5 -enable-batch-mode -index-store-path /home/butta/swift-nio/.build/x86_64-unknown-linux-gnu/debug/index/store -Onone -enable-testing -g -j1 -DSWIFT_PACKAGE -DDEBUG -module-cache-path /home/butta/swift-nio/.build/x86_64-unknown-linux-gnu/debug/ModuleCache -parseable-output -parse-as-library -v
but when translated to the swift-frontend
only the later snapshot adds an unprefixed -emit-dependencies-path
:
Swift version 5.7-dev (LLVM 8bbf73b53c59eeb, Swift a159921d1bf3336)Target: x86_64-unknown-linux-gnu/home/butta/swift-nio/swift-5.7-DEVELOPMENT-SNAPSHOT-2022-04-18-a-ubuntu20.04/usr/bin/swift-frontend -frontend -emit-module -experimental-skip-non-inlinable-function-bodies-without-types /home/butta/swift-nio/Sources/_NIODataStructures/Heap.swift /home/butta/swift-nio/Sources/_NIODataStructures/PriorityQueue.swift -target x86_64-unknown-linux-gnu -disable-objc-interop -I /home/butta/swift-nio/.build/x86_64-unknown-linux-gnu/debug -enable-testing -g -module-cache-path /home/butta/swift-nio/.build/x86_64-unknown-linux-gnu/debug/ModuleCache -swift-version 5 -Onone -D SWIFT_PACKAGE -D DEBUG -new-driver-path /home/butta/swift-nio/swift-5.7-DEVELOPMENT-SNAPSHOT-2022-04-18-a-ubuntu20.04/usr/bin/swift-driver -empty-abi-descriptor -resource-dir /home/butta/swift-nio/swift-5.7-DEVELOPMENT-SNAPSHOT-2022-04-18-a-ubuntu20.04/usr/lib/swift -enable-anonymous-context-mangled-names -module-name _NIODataStructures -emit-module-doc-path /home/butta/swift-nio/.build/x86_64-unknown-linux-gnu/debug/_NIODataStructures.swiftdoc -emit-module-source-info-path /home/butta/swift-nio/.build/x86_64-unknown-linux-gnu/debug/_NIODataStructures.swiftsourceinfo -emit-dependencies-path _NIODataStructures.emit-module.d -parse-as-library -o /home/butta/swift-nio/.build/x86_64-unknown-linux-gnu/debug/_NIODataStructures.swiftmodule
which causes all those files to be dumped in the top level of the package, rather than in .build/
where they belong. I can reproduce with the Apr. 20 trunk snapshot and later for Ubuntu too. Adding -Xswiftc -disallow-use-new-driver
works around the problem.
To Reproduce
swift build
on any Swift package.ls *.emit-module.d
.Expected behavior
No build files dumped outside the .build
directory.
Environment:
Additional context
#1056 most likely caused this problem.
Description
swift build
command prints the same error multiple times. Example output:
% swift build
Building for debugging...
error: emit-module command failed with exit code 1 (use -v to see invocation)
/home/stefan/Dupe/Sources/Dupe/Dupe.swift:4:9: error: consecutive statements on a line must be separated by ';'
let this is error
^
;
/home/stefan/Dupe/Sources/Dupe/Dupe.swift:4:10: error: expected expression
let this is error
^
/home/stefan/Dupe/Sources/Dupe/Dupe.swift:4:5: error: type annotation missing in pattern
let this is error
^
/home/stefan/Dupe/Sources/Dupe/Dupe.swift:4:9: error: consecutive statements on a line must be separated by ';'
let this is error
^
;
/home/stefan/Dupe/Sources/Dupe/Dupe.swift:4:10: error: expected expression
let this is error
^
/home/stefan/Dupe/Sources/Dupe/Dupe.swift:4:5: error: type annotation missing in pattern
let this is error
^
error: fatalError
EDIT: In one of my projects (can't share the source) the error has been duplicated 16 times.
Steps to reproduce
mkdir Dupe
cd Dupe
swift package init
echo "let this is error" > Sources/Dupe/Dupe.swift
swift build
Expected behavior
Each error is displayed only once.
We see a warning each time, compiling in text mode.
Please help here.
~> swift --version
<unknown>:0: warning: using (deprecated) legacy driver, Swift installation does not contain swift-driver at: '/Library/Developer/CommandLineTools/usr/bin/swift-driver-new'
Apple Swift version 6.0 (swiftlang-6.0.0.4.52 clang-1600.0.21.1.3)
Target: arm64-apple-darwin24.0.0
swift run -help
give following:
swift run -help
OVERVIEW: Build and run an executable product
SEE ALSO: swift build, swift package, swift test
USAGE: swift run [<options>] [<executable>] [<arguments> ...]
<rest of output is omitted>
Suggested usage is not quite correct. If there's a need to pass some arguments to executable there's no other way as explicitly use otherwise all are treated as which are passed to driver. I believe correct usage suggestion should be as follows:
USAGE: swift run [<options>] [<executable> [<arguments> ...]]
Description
Use Xcode 14.3 RC 2, set -strict-implicit-module-context flag on Other Swift Flags of Building Settings, when compile swift file, the -strict-implicit-module-context flag only appear swiftc command, does not appear swift-frontend command
Steps to reproduce
1、Use Xcode 14.3 RC 2 , set -strict-implicit-module-context flag on Other Swift Flags of Building Settings
2、Build swift file
3、See swiftc command and swift-frontend command by XCode build message log
Expected behavior
-strict-implicit-module-context flag pass to swift-frontend
Environment
Previous ID | SR-11900 |
Radar | rdar://problem/56924692 |
Original Reporter | @beccadax |
Type | New Feature |
Votes | 1 |
Component/s | Compiler |
Labels | New Feature, Driver, StarterBug |
Assignee | JhonnyBillM (JIRA) |
Priority | Medium |
md5: 1ee0e9c459854e8821d1936d514204b9
Issue Description:
To implement command-line features like "swift build", the Swift driver treats swift <some name>
as though you had written swift-<some name>
. However, it does not respond sensibly to swift help package/build/test/etc
. It would be better if it treated swift help <some name>
as though you had written swift <some name> --help
, and swift help <other args>
as though you had written swift --help <other args>
. (Pretty much all Swift executables handle --help
; a few don't seem to handle -help
.)
This can be implemented in swift-driver's swift-help executable, which is run if the user types "swift help <args>". The implementation of the tool can be found in the swift-driver repository: https://github.com/apple/swift-driver
Describe the bug
I have c library swift wrapper project and I am starting to see errors for all of the c header files included in my project. This didn't happen in Xcode 12 and Xcode 13 but starting to see them after upgraded to Xcode 14.
error: Dependency for P1:target-SwiftSMB-c5b2ccc17d5f0c8fd1175d05f13f3d0683a44e681aeb1f425a9cef51a7a8aacb-:Debug:SwiftDriver Compilation Requirements SwiftSMB normal x86_64 com.apple.xcode.tools.swift.compiler is not absolute (libsmb2/include/smb2/smb2.h). (in target 'SwiftSMB' from project 'SwiftSMB')
...
Showing All Messages Command SwiftDriver Compilation Requirements emitted errors but did not return a nonzero exit code to indicate failure
The error doesn't seem to stop build from completing successfully.
Command line:
SwiftDriver\ Compilation\ Requirements SwiftSMB normal x86_64 com.apple.xcode.tools.swift.compiler (in target 'SwiftSMB' from project 'SwiftSMB') cd /Users/alex/Projects/SwiftSMB builtin-Swift-Compilation-Requirements -- /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc -module-name SwiftSMB -Onone -enforce-exclusivity\=checked @/Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/Objects-normal/x86_64/SwiftSMB.SwiftFileList -DDEBUG -sdk /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator16.0.sdk -target x86_64-apple-ios16.0-simulator -enable-bare-slash-regex -g -module-cache-path /Users/alex/Library/Developer/Xcode/DerivedData/ModuleCache.noindex -Xfrontend -serialize-debugging-options -enable-testing -index-store-path /Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Index.noindex/DataStore -enable-library-evolution -swift-version 5 -I /Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Products/Debug-iphonesimulator -I libsmb2 -I libsmb2/include -I libsmb2/lib -I libsmb2/include/smb2 -F /Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Products/Debug-iphonesimulator -emit-localized-strings -emit-localized-strings-path /Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/Objects-normal/x86_64 -c -j8 -enable-batch-mode -incremental -output-file-map /Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/Objects-normal/x86_64/SwiftSMB-OutputFileMap.json -use-frontend-parseable-output -save-temps -no-color-diagnostics -serialize-diagnostics -emit-dependencies -emit-module -emit-module-path /Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/Objects-normal/x86_64/SwiftSMB.swiftmodule -emit-module-interface-path /Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/Objects-normal/x86_64/SwiftSMB.swiftinterface -emit-private-module-interface-path /Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/Objects-normal/x86_64/SwiftSMB.private.swiftinterface -Xcc -I/Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/swift-overrides.hmap -Xcc -iquote -Xcc /Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/SwiftSMB-generated-files.hmap -Xcc -I/Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/SwiftSMB-own-target-headers.hmap -Xcc -I/Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/SwiftSMB-all-non-framework-target-headers.hmap -Xcc -ivfsoverlay -Xcc /Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/all-product-headers.yaml -Xcc -iquote -Xcc /Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/SwiftSMB-project-headers.hmap -Xcc -I/Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Products/Debug-iphonesimulator/include -Xcc -isystem -Xcc libsmb2/include -Xcc -isystem -Xcc libsmb2/include/smb2 -Xcc -I/Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/DerivedSources-normal/x86_64 -Xcc -I/Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/DerivedSources/x86_64 -Xcc -I/Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/DerivedSources -Xcc -DDEBUG\=1 -emit-objc-header -emit-objc-header-path /Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/Objects-normal/x86_64/SwiftSMB-Swift.h -import-underlying-module -Xcc -ivfsoverlay -Xcc /Users/alex/Library/Developer/Xcode/DerivedData/PhotoBackup2-bnxhcxnjkjxzzbdqwrgkurniflbr/Build/Intermediates.noindex/SwiftSMB.build/Debug-iphonesimulator/SwiftSMB.build/unextended-module-overlay.yaml -working-directory /Users/alex/Projects/SwiftSMB -experimental-emit-module-separately
Environment (please fill out the following information)
Additional context
I have tried cleaning up build folder and rebuild project using Xcode 14 but none of them work.
Currently, all of the options available in the driver are listed in a flat namespace with no logical grouping. It's hard to navigate these options both in the source code and when looking through these options in --help
output. It would be great if options were presented in groups.
When building https://github.com/thebrowsercompany/swift-composable-architecture in release mode, the generated OFM for OpenCombine is invalid, e.g.
Building for production...
<unknown>:0: error: supplementary output file map 'C:\\Users\\abdulras\\AppData\\Local\\Temp\\TemporaryDirectory.T3w0D9\\supplementaryOutputs-1' is missing an entry for 'S:\\SourceCache\\thebrowsercompany\\swift-composable-architecture\\.build\\checkouts\\OpenCombine\\Sources\\OpenCombine\\AnyCancellable.swift' (this likely indicates a compiler issue; please submit a bug report (https://swift.org/contributing/#reporting-bugs))
Note that building OpenCombine directly does not exhibit this issue.
The internal generated state would be correct.
The internal generated state is incorrect.
Swift Package Manager - Swift 5.10.0-dev
swift --version ; uname -a
)Swift version 5.11-dev (LLVM 61776217335130e, Swift 4bcc25e99094074)
Target: x86_64-unknown-windows-msvc
Currently when a vfsoverlay is encountered the incremental logic bails:
remark: Incremental compilation: Could not read TypedVirtualPath(fileHandle: /path/to/Foo.swiftmodule, type: swiftmodule) FileSystemError(kind: TSCBasic.FileSystemError.Kind.noEntry, path: Optional(<AbsolutePath:"/path/to/Foo.swiftmodule">)) '/path/to/Foo.swiftmodule'
/path/to/Foo.swiftmodule
here doesn't exist on the real file system but does in the vfs
When editing this test I found that in the case MultiJobExecutor.execute
fails you get this error with no extra context:
% swift test --filter testDarwinBasic
Building for debugging...
[3/3] Linking swift-driverPackageTests
Build complete! (1.25s)
Test Suite 'Selected tests' started at 2022-06-13 11:31:02.392
Test Suite 'swift-driverPackageTests.xctest' started at 2022-06-13 11:31:02.393
Test Suite 'JobExecutorTests' started at 2022-06-13 11:31:02.393
Test Case '-[SwiftDriverTests.JobExecutorTests testDarwinBasic]' started.
/Users/ksmiley/dev/oss-swift/swift-driver/Sources/SwiftDriverExecution/MultiJobExecutor.swift:310: error: -[SwiftDriverTests.JobExecutorTests testDarwinBasic] : failed: caught error: "fatalError"
Test Case '-[SwiftDriverTests.JobExecutorTests testDarwinBasic]' failed (0.492 seconds).
Test Suite 'JobExecutorTests' failed at 2022-06-13 11:31:02.885.
Executed 1 test, with 1 failure (1 unexpected) in 0.492 (0.492) seconds
Test Suite 'swift-driverPackageTests.xctest' failed at 2022-06-13 11:31:02.885.
Executed 1 test, with 1 failure (1 unexpected) in 0.492 (0.492) seconds
Test Suite 'Selected tests' failed at 2022-06-13 11:31:02.885.
Executed 1 test, with 1 failure (1 unexpected) in 0.492 (0.493) seconds
We should make this output the actual info from the tools that failed
Diagnostics emitted by the driver itself don't obey -parseable-output
. This makes it a bit difficult for clients to handle the output and leads to things like swiftlang/swift-package-manager#5968.
Consider this command line:
❯ swiftc -parseable-output -whole-module-optimization -incremental -c foo.swift
(assuming there is a file foo.swift
). It results in:
remark: Incremental compilation has been disabled: it is not compatible with whole module optimization
1201
{
"command_arguments" : [
"-frontend",
"-c",
"foo.swift",
"-target",
"arm64-apple-macosx12.0",
"-Xllvm",
"-aarch64-use-tbi",
"-enable-objc-interop",
"-stack-check",
. . .
which is a mixture of JSON output and plain-text output. Making matters worse, both the JSON output and the diagnostics are emitted to stderr
. I would have expected that output would go to stdout when -parseable-output
is passed, while the human-readable diagnostics go to stderr
.
Alternatively, when -parseable-output
is in effect, the diagnostics from the driver could be wrapped in JSON packets reflecting the type of diagnostic so that clients don't have to handle a mixture.
After such queries result in target-infos containing double-quoted paths, e.g.:
"sdkPath" : "'C:\\Library\\Developer\\Platforms\\Windows.platform\\Developer\\SDKs\\Windows.sdk'"
This failure is caused by #1335. For now we will disable libSwiftScan target info query on Windows while we understand how to get the paths right here.
Previous ID | SR-12129 |
Radar | rdar://problem/59216637 |
Original Reporter | owenvoorhees (JIRA User) |
Type | Bug |
Status | Resolved |
Resolution | Done |
Votes | 0 |
Component/s | |
Labels | Bug, StarterBug, swift-driver |
Assignee | @robinkunde |
Priority | Medium |
md5: da71f39230ac8067faa7f528905aec25
Issue Description:
For example, invoking the driver with `swiftc -typecheck` will result in `error: no input files` when using the C++ driver, but swift-driver silently exits instead.
I recently opened an issue on the Swift repo (swiftlang/swift#65461) but realised after some debugging that it probabl better fits here.
When trying to build an existing application with a custom toolchain based on the Swift 5.8 Release (swiftlang/swift@f9611bc) the application will not compile due to the Swift Package Manager trying to disallow the new driver.
I noticed that when executing swiftc -version
the output seems to vastly differ. With Xcode's swiftc I get following output:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc -version
swift-driver version: 1.75.2 Apple Swift version 5.8 (swiftlang-5.8.0.124.2 clang-1403.0.22.11.100)
Target: arm64-apple-macosx13.0
while with the custom compiler I get following output:
/Library/Developer/Toolchains/swift-LOCAL-2023-05-02-a.xctoolchain/usr/bin/swift-frontend -version
Apple Swift version 5.8 (swift-5.8-RELEASE)
Target: arm64-apple-macosx13.0
To me it looks like there are some issues with the custom compiled toolchain choosing the wrong driver. Is there any easy-fix for this?
There seems to be nothing that deletes this temporary directory at least not on Linux. Leading to lots of left over /tmp/TemporaryDirectory-/dummyInput-.swift files. If all is needed is an empty swift file maybe it should just exist in the toolchain directory and only create a temporary directory if that file doesn't exist?
continuing from swiftlang/vscode-swift#416
lookupToolPath function in WindowsToolchain.swift don't know about cross compilation case.
Patch:
diff -rupN original/Sources/SwiftDriver/Toolchains/WindowsToolchain.swift new/Sources/SwiftDriver/Toolchains/WindowsToolchain.swift
--- original/Sources/SwiftDriver/Toolchains/WindowsToolchain.swift 2022-09-12 10:01:08.000000000 +0300
+++ new/Sources/SwiftDriver/Toolchains/WindowsToolchain.swift 2022-09-16 11:57:36.000000000 +0300
@@ -67,29 +67,34 @@ extension WindowsToolchain.ToolchainVali
}
private func lookupToolPath(_ tool: Tool) throws -> AbsolutePath {
+#if os(Windows)
+ let ext = ".exe"
+#else
+ let ext = ""
+#endif
switch tool {
case .swiftAPIDigester:
- return try lookup(executable: "swift-api-digester.exe")
+ return try lookup(executable: "swift-api-digester" + ext)
case .swiftCompiler:
- return try lookup(executable: "swift-frontend.exe")
+ return try lookup(executable: "swift-frontend" + ext)
case .staticLinker:
- return try lookup(executable: "lld-link.exe")
+ return try lookup(executable: "lld-link" + ext)
case .dynamicLinker:
- return try lookup(executable: "clang.exe")
+ return try lookup(executable: "clang" + ext)
case .clang:
- return try lookup(executable: "clang.exe")
+ return try lookup(executable: "clang" + ext)
case .clangxx:
- return try lookup(executable: "clang++.exe")
+ return try lookup(executable: "clang++" + ext)
case .swiftAutolinkExtract:
- return try lookup(executable: "swift-autolink-extract.exe")
+ return try lookup(executable: "swift-autolink-extract" + ext)
case .lldb:
- return try lookup(executable: "lldb.exe")
+ return try lookup(executable: "lldb" + ext)
case .dsymutil:
- return try lookup(executable: "llvm-dsymutil.exe")
+ return try lookup(executable: "llvm-dsymutil" + ext)
case .dwarfdump:
- return try lookup(executable: "llvm-dwarfdump.exe")
+ return try lookup(executable: "llvm-dwarfdump" + ext)
case .swiftHelp:
- return try lookup(executable: "swift-help.exe")
+ return try lookup(executable: "swift-help" + ext)
}
}
On my MacBookPro18,2 running macOS Ventura 13.2.1 and Xcode 14.1 I happened to bring up Console and found 6 swift-driver
crash reports. They all seem to be due to an assertion in libswiftCore
. I have no idea what triggered these failures. I tried to reproduce the crash but was unable to do so.
Translated Report (Full Report Below)
-------------------------------------
Process: swift-driver [21971]
Path: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-driver
Identifier: swift-driver
Version: ???
Code Type: ARM-64 (Native)
Parent Process: XCBBuildService [2145]
Responsible: Xcode [2113]
User ID: 503
Date/Time: 2023-03-06 18:51:34.6341 -0500
OS Version: macOS 13.2.1 (22D68)
Report Version: 12
Anonymous UUID: C8F97525-3322-572C-B9CE-A91EB243AC3C
Time Awake Since Boot: 13000 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x00000001bd4cc218
Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5
Terminating Process: exc handler [21971]
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libswiftCore.dylib 0x1bd4cc218 _assertionFailure(_:_:file:line:flags:) + 316
1 libswiftCore.dylib 0x1bd4cc218 _assertionFailure(_:_:file:line:flags:) + 316
2 swift-driver 0x102078058 main + 2648
3 dyld 0x1af3c3e50 start + 2544
Thread 1:
0 libsystem_pthread.dylib 0x1af6e8e18 start_wqthread + 0
Thread 2:
0 libsystem_pthread.dylib 0x1af6e8e18 start_wqthread + 0
Thread 3:
0 libsystem_pthread.dylib 0x1af6e8e18 start_wqthread + 0
Thread 4:
0 libsystem_pthread.dylib 0x1af6e8e18 start_wqthread + 0
Thread 5:
0 libsystem_pthread.dylib 0x1af6e8e18 start_wqthread + 0
Thread 0 crashed with ARM Thread State (64-bit):
x0: 0x80000001025162d0 x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x0000600002275b00
x4: 0x0000000000000000 x5: 0x000000016dd89350 x6: 0x0000000000000073 x7: 0x0000000000000001
x8: 0x0000000000000100 x9: 0x00000000000000ff x10: 0x0000000000001ac0 x11: 0x00000000000007fb
x12: 0x00000000cf049ffb x13: 0x00000000000007fd x14: 0x00000000cf24a06c x15: 0x00000000cf049ffb
x16: 0x000000000000006c x17: 0x000000004f200000 x18: 0x0000000000000000 x19: 0x80000001025162d0
x20: 0x0000000000000002 x21: 0x0000000000000000 x22: 0x0000000000000017 x23: 0x00000001025162d0
x24: 0xd000000000000025 x25: 0x0000000102516d20 x26: 0x000000000000000b x27: 0x00000001025d6280
x28: 0x0000000000000000 fp: 0x000000016dd894a0 lr: 0x00000001bd4cc218
sp: 0x000000016dd89420 pc: 0x00000001bd4cc218 cpsr: 0x60001000
far: 0x0000000102f3c610 esr: 0xf2000001 (Breakpoint) brk 1
Binary Images:
0x1bd495000 - 0x1bd9e2fff libswiftCore.dylib (*) <5034430d-70ab-3345-9d7d-f5e05067eeb2> /usr/lib/swift/libswiftCore.dylib
0x102074000 - 0x10258ffff swift-driver (*) <62d33a8b-561b-3fd0-ae9c-b467417e714b> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-driver
0x1af3be000 - 0x1af448ba3 dyld (*) <191e84f1-4b95-39c8-b253-1c1ef56c0fa8> /usr/lib/dyld
0x1af6e7000 - 0x1af6f3ffb libsystem_pthread.dylib (*) <9f3b729a-ed04-3e65-adac-d75ad06ebbdc> /usr/lib/system/libsystem_pthread.dylib
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 20
thread_create: 0
thread_set_state: 800
VM Region Summary:
ReadOnly portion of Libraries: Total=940.3M resident=0K(0%) swapped_out_or_unallocated=940.3M(100%)
Writable regions: Total=851.3M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=851.3M(100%)
VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
Activity Tracing 256K 1
Kernel Alloc Once 32K 1
MALLOC 216.2M 27
MALLOC guard page 96K 5
MALLOC_MEDIUM (reserved) 240.0M 2 reserved VM address space (unallocated)
MALLOC_NANO (reserved) 384.0M 1 reserved VM address space (unallocated)
STACK GUARD 56.1M 6
Stack 10.6M 6
VM_ALLOCATE 16K 1
__AUTH 461K 102
__AUTH_CONST 8023K 230
__DATA 2488K 218
__DATA_CONST 9444K 232
__DATA_DIRTY 445K 84
__FONT_DATA 2352 1
__LINKEDIT 776.7M 2
__OBJC_CONST 643K 81
__OBJC_RO 65.5M 1
__OBJC_RW 1988K 1
__TEXT 163.6M 241
dyld private memory 256K 1
mapped file 29.1M 2
shared memory 624K 7
=========== ======= =======
TOTAL 1.9G 1253
TOTAL, minus reserved VM space 1.3G 1253
-----------
Full Report
-----------
{"app_name":"swift-driver","timestamp":"2023-03-06 18:51:34.00 -0500","app_version":"","slice_uuid":"62d33a8b-561b-3fd0-ae9c-b467417e714b","build_version":"","platform":1,"share_with_app_devs":0,"is_first_party":1,"bug_type":"309","os_version":"macOS 13.2.1 (22D68)","roots_installed":0,"incident_id":"122C3082-7A47-4F5E-9EE7-51CE476B11FA","name":"swift-driver"}
{
"uptime" : 13000,
"procRole" : "Unspecified",
"version" : 2,
"userID" : 503,
"deployVersion" : 210,
"modelCode" : "MacBookPro18,2",
"coalitionID" : 1258,
"osVersion" : {
"train" : "macOS 13.2.1",
"build" : "22D68",
"releaseType" : "User"
},
"captureTime" : "2023-03-06 18:51:34.6341 -0500",
"incident" : "122C3082-7A47-4F5E-9EE7-51CE476B11FA",
"pid" : 21971,
"translated" : false,
"cpuType" : "ARM-64",
"roots_installed" : 0,
"bug_type" : "309",
"procLaunch" : "2023-03-06 18:51:33.5509 -0500",
"procStartAbsTime" : 330378302183,
"procExitAbsTime" : 330404288671,
"procName" : "swift-driver",
"procPath" : "\/Applications\/Xcode.app\/Contents\/Developer\/Toolchains\/XcodeDefault.xctoolchain\/usr\/bin\/swift-driver",
"parentProc" : "XCBBuildService",
"parentPid" : 2145,
"coalitionName" : "com.apple.dt.Xcode",
"crashReporterKey" : "C8F97525-3322-572C-B9CE-A91EB243AC3C",
"responsiblePid" : 2113,
"responsibleProc" : "Xcode",
"sip" : "enabled",
"exception" : {"codes":"0x0000000000000001, 0x00000001bd4cc218","rawCodes":[1,7470891544],"type":"EXC_BREAKPOINT","signal":"SIGTRAP"},
"termination" : {"flags":0,"code":5,"namespace":"SIGNAL","indicator":"Trace\/BPT trap: 5","byProc":"exc handler","byPid":21971},
"os_fault" : {"process":"swift-driver"},
"extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":800,"task_for_pid":20},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
"faultingThread" : 0,
"threads" : [{"triggered":true,"id":180731,"threadState":{"x":[{"value":9223372041188631248},{"value":0},{"value":0},{"value":105553152400128},{"value":0},{"value":6137877328},{"value":115},{"value":1},{"value":256},{"value":255},{"value":6848},{"value":2043},{"value":3473186811},{"value":2045},{"value":3475284076},{"value":3473186811},{"value":108},{"value":1327497216},{"value":0},{"value":9223372041188631248},{"value":2},{"value":0},{"value":23},{"value":4333855440},{"value":14987979559889010725},{"value":4333858080},{"value":11},{"value":4334641792,"symbolLocation":0,"symbol":"localFileSystem"},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":7470891544},"cpsr":{"value":1610616832},"fp":{"value":6137877664},"sp":{"value":6137877536},"esr":{"value":4060086273,"description":"(Breakpoint) brk 1"},"pc":{"value":7470891544,"matchesCrashFrame":1},"far":{"value":4344497680}},"queue":"com.apple.main-thread","frames":[{"imageOffset":225816,"symbol":"_assertionFailure(_:_:file:line:flags:)","symbolLocation":316,"imageIndex":0},{"imageOffset":225816,"symbol":"_assertionFailure(_:_:file:line:flags:)","symbolLocation":316,"imageIndex":0},{"imageOffset":16472,"symbol":"main","symbolLocation":2648,"imageIndex":1},{"imageOffset":24144,"symbol":"start","symbolLocation":2544,"imageIndex":2}]},{"id":180732,"frames":[{"imageOffset":7704,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":3}]},{"id":180736,"frames":[{"imageOffset":7704,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":3}]},{"id":180750,"frames":[{"imageOffset":7704,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":3}]},{"id":180760,"frames":[{"imageOffset":7704,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":3}]},{"id":180761,"frames":[{"imageOffset":7704,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":3}]}],
"usedImages" : [
{
"source" : "P",
"arch" : "arm64e",
"base" : 7470665728,
"size" : 5562368,
"uuid" : "5034430d-70ab-3345-9d7d-f5e05067eeb2",
"path" : "\/usr\/lib\/swift\/libswiftCore.dylib",
"name" : "libswiftCore.dylib"
},
{
"source" : "P",
"arch" : "arm64",
"base" : 4328996864,
"size" : 5357568,
"uuid" : "62d33a8b-561b-3fd0-ae9c-b467417e714b",
"path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Toolchains\/XcodeDefault.xctoolchain\/usr\/bin\/swift-driver",
"name" : "swift-driver"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 7234904064,
"size" : 568228,
"uuid" : "191e84f1-4b95-39c8-b253-1c1ef56c0fa8",
"path" : "\/usr\/lib\/dyld",
"name" : "dyld"
},
{
"source" : "P",
"arch" : "arm64e",
"base" : 7238217728,
"size" : 53244,
"uuid" : "9f3b729a-ed04-3e65-adac-d75ad06ebbdc",
"path" : "\/usr\/lib\/system\/libsystem_pthread.dylib",
"name" : "libsystem_pthread.dylib"
}
],
"sharedCache" : {
"base" : 7234256896,
"size" : 3447455744,
"uuid" : "835716ae-b363-3187-b065-cf94139bfc85"
},
"vmSummary" : "ReadOnly portion of Libraries: Total=940.3M resident=0K(0%) swapped_out_or_unallocated=940.3M(100%)\nWritable regions: Total=851.3M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=851.3M(100%)\n\n VIRTUAL REGION \nREGION TYPE SIZE COUNT (non-coalesced) \n=========== ======= ======= \nActivity Tracing 256K 1 \nKernel Alloc Once 32K 1 \nMALLOC 216.2M 27 \nMALLOC guard page 96K 5 \nMALLOC_MEDIUM (reserved) 240.0M 2 reserved VM address space (unallocated)\nMALLOC_NANO (reserved) 384.0M 1 reserved VM address space (unallocated)\nSTACK GUARD 56.1M 6 \nStack 10.6M 6 \nVM_ALLOCATE 16K 1 \n__AUTH 461K 102 \n__AUTH_CONST 8023K 230 \n__DATA 2488K 218 \n__DATA_CONST 9444K 232 \n__DATA_DIRTY 445K 84 \n__FONT_DATA 2352 1 \n__LINKEDIT 776.7M 2 \n__OBJC_CONST 643K 81 \n__OBJC_RO 65.5M 1 \n__OBJC_RW 1988K 1 \n__TEXT 163.6M 241 \ndyld private memory 256K 1 \nmapped file 29.1M 2 \nshared memory 624K 7 \n=========== ======= ======= \nTOTAL 1.9G 1253 \nTOTAL, minus reserved VM space 1.3G 1253 \n",
"legacyInfo" : {
"threadTriggered" : {
"queue" : "com.apple.main-thread"
}
},
"trialInfo" : {
"rollouts" : [
{
"rolloutId" : "60f8ddccefea4203d95cbeef",
"factorPackIds" : {
},
"deploymentId" : 240000025
},
{
"rolloutId" : "63582c5f8a53461413999550",
"factorPackIds" : {
},
"deploymentId" : 240000002
}
],
"experiments" : [
]
}
}
Previous ID | SR-13255 |
Radar | None |
Original Reporter | owenvoorhees (JIRA User) |
Type | Improvement |
Votes | 0 |
Component/s | |
Labels | Improvement, StarterBug, swift-driver |
Assignee | srinikhil07 (JIRA) |
Priority | Medium |
md5: fc54056e575ca013a03072c8d28f5400
Issue Description:
The current argument validation implementation specific to Darwin platforms (macOS, iOS, etc.) is incomplete. DarwinToolchain.validateArguments contains a number of TODOs for porting over validation steps from the C++ driver. The original implementation of these checks can be found here: https://github.com/apple/swift/blob/d3ecf8848ede62368896410ec6b891c1a34f2e4c/lib/Driver/DarwinToolChains.cpp#L932
swift ./-
should try and read the file named -
in the current folder. Instead it reads from stdin, just like swift -
.
-
in your cwd;swift ./-
Swift should execute the file just created.
swift-driver version: 1.87.3 Apple Swift version 5.9.2 (swiftlang-5.9.2.2.56 clang-1500.1.0.2.5)
Target: arm64-apple-macosx14.0
No response
Hello 👋🏻
I am investigating a bug and I'm not sure if I'm doing something wrong or if the code is not working correctly, can you help me understanding what's happening?
I am packaging Swift for Exherbo.
For various reasons, I'm still working on the Swift 5.7, using the release/5.7
branches.
When I run swift build
, I get error: unknown or missing subcommand 'swift-build'
The error is thrown from apple/swift-driver/Sources/swift-driver/main.swift#L68-L75.
I added a few print
statements so I can see what's happening:
// We are running as a subcommand, try to find the subcommand adjacent to the executable we are running as.
// If we didn't find the tool there, let the OS search for it.
+ print("arguments", arguments)
+ print("path1", String(describing: Process.findExecutable(arguments[0])?.parentDirectory.appending(component: subcommand)))
let subcommandPath = Process.findExecutable(arguments[0])?.parentDirectory.appending(component: subcommand)
?? Process.findExecutable(subcommand)
To my surprise, while I expected arguments
to be something like ["/usr/x86_64-pc-linux-gnu/lib/swift-5.7/Developer/Toolchains/unknown-Asserts-development.xctoolchain/usr/bin/swift", "build"]
, it says ["swift-build"]
!
To my surprise, while I expected arguments
to be something like ["/usr/x86_64-pc-linux-gnu/lib/swift-5.7/Developer/Toolchains/unknown-Asserts-development.xctoolchain/usr/bin/swift", "build"]
(allowing swift-driver
to find the adjacent swift-build
binary), it says ["swift-build"]
!
$ /usr/x86_64-pc-linux-gnu/lib/swift-5.7/Developer/Toolchains/unknown-Asserts-development.xctoolchain/usr/bin/swift build
arguments ["swift-build"]
path1 nil
error: unknown or missing subcommand 'swift-build'
(The same happens with swift build
by the way)
$ swift build
arguments ["swift-build"]
path1 nil
error: unknown or missing subcommand 'swift-build'
Yes, swift-build
exists and is next to swift
and swift-driver
.
Yes, adding swift-build
' parent directory (/usr/x86_64-pc-linux-gnu/lib/swift-5.7/Developer/Toolchains/unknown-Asserts-development.xctoolchain/usr/bin
) to the PATH
fixes the issue, but it's not what I want.
This seems like a bug to me, CommandLine.arguments
should not return swift-build
yet 🤔
With nightly build of swift 6 I keep seeing duplicate error diagnostics getting output. This was showing up intermittently on macOS but is consistent on Linux.
Create a swift executable with "swift package init". Any error should reproduce:
print("Hello, world!")
let f = 1
f = 2
Build and notice the duplicate error diagnostic
$ swift build --build-tests
Building for debugging...
error: emit-module command failed with exit code 1 (use -v to see invocation)
/home/vscode/swift-executable/Sources/main.swift:6:1: error: cannot assign to value: 'f' is a 'let' constant
3 |
4 | print("Hello, world!")
5 | let f = 1
| - note: change 'let' to 'var' to make it mutable
6 | f = 2
| - error: cannot assign to value: 'f' is a 'let' constant
7 |
/home/vscode/swift-executable/Sources/main.swift:6:1: error: cannot assign to value: 'f' is a 'let' constant
3 |
4 | print("Hello, world!")
5 | let f = 1
| - note: change 'let' to 'var' to make it mutable
6 | f = 2
| - error: cannot assign to value: 'f' is a 'let' constant
7 |
Same when using "llvm" format:
$ swift build -Xswiftc -diagnostic-style=llvm
Building for debugging...
error: emit-module command failed with exit code 1 (use -v to see invocation)
/home/vscode/swift-executable/Sources/main.swift:6:1: error: cannot assign to value: 'f' is a 'let' constant
f = 2
^
/home/vscode/swift-executable/Sources/main.swift:5:1: note: change 'let' to 'var' to make it mutable
let f = 1
^~~
var
/home/vscode/swift-executable/Sources/main.swift:6:1: error: cannot assign to value: 'f' is a 'let' constant
f = 2
^
/home/vscode/swift-executable/Sources/main.swift:5:1: note: change 'let' to 'var' to make it mutable
let f = 1
^~~
var
No duplicate diagnostics
Using the swiftlang/swift:nightly-6.0-jammy docker image
$ swift -version
Swift version 6.0-dev (LLVM 4b0b1f9e1a69523, Swift 91a3abcf816bc36)
Target: aarch64-unknown-linux-gnu
No response
Using -enable-batch-mode results in a link failure as wrong object file name is used.
$ swiftc -enable-batch-mode ~/hw.swift
error: link command failed with exit code 1 (use -v to see invocation)
clang: error: no such file or directory: '/var/folders/cl/z48nl9xx18307rwb9l42n2yr0000gn/T/TemporaryDirectory.u1TWon/hw-1.o'
clang: error: no input files
error: fatalError
The frontend generates /var/folders/cl/z48nl9xx18307rwb9l42n2yr0000gn/T/TemporaryDirectory.IYWkMJ/hw-2.o but then tries to link /var/folders/cl/z48nl9xx18307rwb9l42n2yr0000gn/T/TemporaryDirectory.IYWkMJ/hw-1.o
$ SWIFT_EXEC=/Users/ryan_mansfield/swift/build/Ninja-RelWithDebInfoAssert/swiftdriver-macosx-arm64/arm64-apple-macosx10.14/release/bin/swiftc SWIFT_DRIVER_SWIFT_FRONTEND_EXEC=~/swift/build/Ninja-ReleaseAssert/swift-macosx-arm64/bin/swift-frontend swiftc -enable-batch-mode ~/hw.swift -v
Swift version 6.0-dev (LLVM 57177aa1b91540b, Swift 85c0555c89e568d)
Target: arm64-apple-macosx14.0
/Users/ryan_mansfield/swift/build/Ninja-ReleaseAssert/swift-macosx-arm64/bin/swift-frontend -frontend -c -primary-file /Users/ryan_mansfield/hw.swift -target arm64-apple-macosx14.0 -Xllvm -aarch64-use-tbi -enable-objc-interop -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk -color-diagnostics -new-driver-path /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift-driver -empty-abi-descriptor -resource-dir /Users/ryan_mansfield/swift/build/Ninja-ReleaseAssert/swift-macosx-arm64/lib/swift -module-name hw -disable-clang-spi -target-sdk-version 14.4 -target-sdk-name macosx14.4 -external-plugin-path '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk/usr/lib/swift/host/plugins#/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk/usr/bin/swift-plugin-server' -external-plugin-path '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk/usr/local/lib/swift/host/plugins#/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk/usr/bin/swift-plugin-server' -external-plugin-path '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/lib/swift/host/plugins#/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/bin/swift-plugin-server' -external-plugin-path '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/local/lib/swift/host/plugins#/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/usr/bin/swift-plugin-server' -plugin-path /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/host/plugins -plugin-path /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/local/lib/swift/host/plugins -o /var/folders/cl/z48nl9xx18307rwb9l42n2yr0000gn/T/TemporaryDirectory.IYWkMJ/hw-2.o
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang /var/folders/cl/z48nl9xx18307rwb9l42n2yr0000gn/T/TemporaryDirectory.IYWkMJ/hw-1.o --sysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk --target=arm64-apple-macosx14.0 -L /Users/ryan_mansfield/swift/build/Ninja-ReleaseAssert/swift-macosx-arm64/lib/swift/macosx -L /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.4.sdk/usr/lib/swift -o hw
error: link command failed with exit code 1 (use -v to see invocation)
clang: error: no such file or directory: '/var/folders/cl/z48nl9xx18307rwb9l42n2yr0000gn/T/TemporaryDirectory.IYWkMJ/hw-1.o'
clang: error: no input files
error: fatalError
Using the older driver works:
$ SWIFT_USE_OLD_DRIVER=1 SWIFT_EXEC=/Users/ryan_mansfield/swift/build/Ninja-RelWithDebInfoAssert/swiftdriver-macosx-arm64/arm64-apple-macosx10.15/release/bin/swiftc SWIFT_DRIVER_SWIFT_FRONTEND_EXEC=~/swift/build/Ninja-ReleaseAssert/swift-macosx-arm64/bin/swift-frontend swiftc -enable-batch-mode ~/hw.swift
<unknown>:0: warning: legacy driver is now deprecated; consider avoiding specifying 'SWIFT_USE_OLD_DRIVER'
$ echo $?
0
Link executable successfully.
Swift version 6.0-dev (LLVM 57177aa1b91540b, Swift 85c0555c89e568d)
No response
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.