The swift-driver project is a new implementation of the Swift compiler driver that is intended to replace the existing driver with a more extensible, maintainable, and robust code base. The Swift compiler’s driver is what handles the build of a Swift module: it runs the Swift compiler frontend to compile source code to object files, the linker to link those object files into a library or executable, and so on, and contains much of the knowledge of how to produce working programs for any given platform. The driver is the main program that build systems (e.g. SwiftPM, xcodebuild, make, ninja) interact with to compile Swift code, so it is a key piece of infrastructure for building Swift code. The new swift-driver is architected as a Swift library, allowing for deeper integration with the Swift Package Manager.
The new swift-driver is designed to be a drop-in replacement for the existing Swift compiler driver. It is already suitable for many build tasks on Darwin and Linux, but there is also a significant amount of functionality that still needs to be implemented for it to become a viable replacement for the existing driver. swift-driver is open source as part of the Swift project, and we could use your help to make that happen! No compiler experience is necessary, and it’s a relatively small Swift code base using modern Swift development practices (SwiftPM, Foundation, XCTest, etc.) with a specific development plan containing tasks for all skill levels.
Once we have reached feature parity with the existing driver, we intend to deprecate the existing driver and replace it with this new implementation.
Oh wow, I hope this is just the first of re-writing the Swift compiler using Swift itself (in the very very long term). I'll try to take a closer look soon and see if there is anything even I could help with. Love it.
You'll need Swift to build Swift. If you don't have Swift on the platform you're targeting, you'll need to cross-compile. We're going to cross this bridge at some point, and it'll probably require us to improve our cross-compilation story.
I‘m just bumping this collect some feedback on the WASM idea - we have a more-or-less working prototype on swiftwasm.org (there are still some issues around relocations and relative pointers).
WASM is now the official fourth-supported language for the web after gaining the W3C‘s blessing. Basically all supported (and semi-supported) platforms can run a browser or WASM host in some form. That seems to me to make it an ideal lowest-common-denominator target for bootstrapping a fully-native toolchain.
It appears to be relatively straightforward to port Clang to WASM, so I imagine it shouldn’t be much more difficult to port the Swift compiler, either. (To summarise that talk: WASI provides almost all of POSIX, except a filesystem. Shim in an in-memory filesystem and basically everything „just works“).
If we recognise this port as a „strategic priority“, I‘m sure we could get the remaining issues resolved without a huge amount of work.
Personally, I don’t know enough about linkers to help with that issue. I’ve been reading up to try and help, but since so many languages already compile to WASM without issue, I get the feeling there is an obvious solution that somebody with more knowledge would immediately spot. If we recognised the strategic importance of a WASM port, maybe somebody such as @Joe_Groff or @John_McCall would be able to spend some time helping us bring the port up? (Come on guys, it’s Christmas-time! )
EDIT: another benefit of using WASM to bootstrap - it means the swift-driver project and any other parts of the compiler written in Swift would be able to use the latest language features. We don’t need to care about which version of Swift is already installed on your platform, because we won’t use that compiler — we’ll execute a WASM version of the latest Swift compiler, supporting all the latest stuff, which runs in a sandbox but can output a fully-native version of the compiler - including any portions that may be written in Swift itself.
)