The new Swift compiler Driver written in Swift

Development Compiler
1

Swift 5.5 was the first release to move some components of the compiler itself from C++ to Swift, the new swift-driver and swift-help binaries (the Swift package manager binaries like swift-build and swift-test were already written in Swift).

$ ./swift-5.5-RELEASE-centos8/usr/bin/swift -h -v
Swift version 5.5 (swift-5.5-RELEASE)
Target: x86_64-unknown-linux-gnu
/home/butta/swift-5.5-RELEASE-centos8/usr/bin/swift-help swift
OVERVIEW: Swift compiler
...

Did you notice this or has it made any difference in your builds? I thought it would be good to gather feedback before the Swift devs move more components of the compiler to Swift, such as with the next libswift effort. I did hit a couple small bugs with the new swift-driver: one was fixed by @compnerd in trunk and will be in the next 5.5 snapshot build, the other is a small bug I fixed in trunk which hasn't been merged into the 5.5 branch yet.

The tokei code count program reports 9.7 klocs in the old C++ Driver in include/swift/Driver/ and lib/Driver/, and 20.7 klocs in the new swift-driver's Sources/. That's not apples to apples, as the third-largest Swift file in swift-driver is a port of LLVM's compilation triple parser to 1.25 klocs of Swift, whereas the old C++ Driver can include that C++ file from LLVM directly.

Comparing the largest file in each repo, it is no contest for me: I'd much rather read and work in Swift.

What do you think of the new swift-driver and moving more of the compiler to be written in Swift?

5 Likes
2

I think that having part of the toolchain written in Swift is great as it lower the entry cost for SE proposal which requires a working implementation.

Also, I suspect most today Swift developers (including me) would not be able to contribute without learning more about compilers but maybe those could find more approchable to build tooling interacting with those Swift components. Maybe those already building tooling could go a bit deeper in the toolchain.

I remember it was stated that writing the whole compiler in Swift wasn't a goal per se but having front end components written in Swift might make Swift tooling better and from what I get It's something that need improvements for Swift to thrive on platforms other than Apple's.

2 Likes
3

I'm poking around in the driver and frontend, and am delighted to be able to work in Swift on the driver. It's a much more pleasant language than C++.

I do wonder what the timeline is for removing the old driver from the toolchain.

4

I do wonder what the timeline is for removing the old driver from the toolchain.

The plan appears to be to maintain both the old driver written in C++ and the new one written in Swift, according to a comment from the thread I linked above.

This causes problems when the two drivers fall out of sync, for example, I was not able to compile the stdlib with the new swift driver natively on Android when I tried it last month with the Oct. 21 trunk source snapshot. The new driver complains that it cannot find the flags -disable-autolinking-runtime-compatibility-concurrency and -disable-implicit-distributed-module-import, but if I pass in --skip-early-swift-driver to use the old driver instead, it builds fine.

One reason these regressions creep in is the new swift driver is not used on the linux CI when running the compiler validation suite or building the corelibs, because there is no prebuilt Swift toolchain installed on the linux CI. It is tested on macOS however, so I'm not sure how my particular problem happens.

I advocated in the first linked thread to just ditch the old driver, which would require current platforms to build the new driver with a prebuilt Swift toolchain and future platform ports of Swift to cross-compile a bootstrap compiler.

2 Likes
5

This causes problems when the two drivers fall out of sync, for example, I was not able to compile the stdlib with the new swift driver natively on Android when I tried it last month with the Oct. 21 trunk source snapshot.

Turns out out-of-sync drivers was not the issue, instead it was the issue that Artem was trying to fix in my second link, that a symlinked swift-driver then tries to build with the prebuilt Swift toolchain and not the one you are freshly building. I had run into this issue months earlier on linux, but didn't connect it to this instance on Android because the errors were different. Simply copying over swift-driver manually instead fixed it, and that's what Artem's merged pull already did in trunk a couple days after the Oct. 21 tag I built, so this is fixed now.