After its announcement almost exactly a year ago, the swift-driver project is moving full-steam-ahead towards the goal of replacing its C++ predecessor. Recent weeks saw a large amount of activity on the swift-driver repository towards achieving that goal. A few highlights:
@David_Ungar2 has been building out incremental build support [1] [2].
@owenv has been making huge strides in chipping away the outstanding lit test failures when using swift-driver as a drop-in replacement for the C++ driver. ([3], [4], [5], and many more)
We now build and package both the swift-driver executable and libSwiftDriver shared library in our toolchain snapshots.
@stevapple has started work on implementing the Windows-specific toolchain abstraction [6].
Over the years, the C++ driver has included many efforts to support additional platforms (e.g. WebAssembly, Android). Catching up on supported platforms is one of the major outstanding considerations in making a switch to using swift-driver as the default. With the progress we've been making, it is now prudent to call attention of platform maintainers to this upcoming change.
We are very excited to have a significant component of the compiler written in Swift itself. There are many ways to get involved with this effort in either bringup of missing platform support and general improvements to the new driver:
You can now use the new driver as a direct drop-in by setting an environment variable (SWIFT_USE_NEW_DRIVER) [7]. Alternative instructions here. Exercising the new driver in this fashion is extremely valuable for increasing coverage of potential use-cases.
Comment on this forum post for any and all discussion and concerns about this effort.
Iām also really excited by the progress that has been made on C++ interop by the TensorFlow team. The idea to transition more of the compiler to Swift is suddenly looking kind-of... feasible, actually!
Catching up on supported platforms is one of the major outstanding considerations in making a switch to using swift-driver as the default.
It is not clear if you're worried about compiling swift-driver itself for these platforms, using it for them, or both. The former has always worked great, as I've built it a handful of times natively on Android since it was made a part of the SPM build in the main branch in May without a problem.
I had assumed using it was made the default in SPM at some point, but I now see that's not the case. I recently built and tested the Oct. 15 source snapshot on Android, so I just tried enabling the integrated swift driver when building and testing SPM. A single new test failed both before and after enabling swift-driver, so it looks like it's at parity with the C++ driver on that SPM package:
<EXPR>:0: error: BuildPlanTests.testExplicitSwiftPackageBuild : threw error "jobFailedWithNonzeroExitCode(1, "swift (LLVM option parsing): for the --aarch64-use-tbi option: may only occur zero or one times!\n")"
There isn't much Android-specific code in the C++ driver, as it's basically a linux distro with a different libc than glibc, but I'll check those few instances and submit a pull if needed.
It could be in the future, when we start testing the new driver in our environment. As for the current state of things, WebAssembly support has landed a couple of days ago thanks to the amazing work by Owen Voorhees.
Speaking only for myself, I think using swift-driver to compile for these platforms is the primary concern, as it should already compile on most of them (assuming Foundation and libDispatch are available).
In case it's helpful to anyone working on ports, I put together some (non-exhaustive) notes on the platform support that I know is missing currently:
Windows support hasn't landed yet and differs significantly from other targets, but it seems like there's a clear path forward and the existing test coverage is pretty good, so I won't enumerate all the differences here
On Android, sanitizer runtime library names are not computed correctly, the linker target normalization from toolchains::Android::getTargetForLinker in the C++ driver isn't implemented yet, and there's no toolchain assigned to the platform
On OpenBSD, the custom default linker selection isn't implemented yet, and there's no toolchain assigned to the platform
Cygwin also has custom default linker selection that isn't implemented yet, and there's no toolchain assigned to the platform
PS4 is not excluded from swift-autolink-extract usage yet, and there's no toolchain assigned to the platform
FreeBSD support might work as-is, but it's untested
Haiku support might work as-is, but it's untested and it's quite possible we're using some APIs that aren't available on that platform
Of these, the Cygwin, PS4, FreeBSD, and Haiku ports are all fairly old, so I'm not sure how well they're supported nowadays.
