Shipping clang with the Swift toolchains

This has always seemed weird to me: I've never quite understood why we went to all the effort of building a clang only to not ship it.

Regardless, this would be very useful if we go ahead with RFC: Moving SwiftNIO SSL to BoringSSL, as it would guarantee the use of a recent clang compiler when building BoringSSL. This reduces the risk that BoringSSL ages out of some of the quite ancient clang versions that are floating around in the Swift ecosystem.

1 Like