Build without swift host tools #77815
Conversation
…swift-syntax When building without swift-syntax, we don't have the ability to handle macros. However, the concurrency runtime makes use of `#isolation` in a number of places. To continue supporting building without swift-syntax, parse `#isolation` directly into the otherwise-unspellable CurrentContextIsolationExpr but *only* when swift-syntax is not available.
DougGregor
requested review from
a team,
hborla,
slavapestov,
xedin,
ahoppen,
bnbarham,
CodaFi,
hamishknight and
rintaro
as code owners
|
The preset comes from #77795 |
|
preset=buildbot_linux,without_host_swift |
1 similar comment
|
preset=buildbot_linux,without_host_swift |
Based on a patch from Evan Wilde, introduce a new preset that disables the features that require Swift host tools. This involves disabling early swift-syntax (used in the compiler for macros et al) and early swift-driver.
DougGregor
force-pushed
the
build-without-swift-host-tools
branch
from
8c53569
to
e333144
Compare
|
preset=buildbot_linux,without_host_swift |
These annotations require optimization passes that are written in Swift, so we need a host Swift compiler to properly process them. Use `hasFeature(Macros)` as a way to gate the annotations.
|
preset=buildbot_linux,without_host_swift |
|
Next failure is... |
… written in Swift
|
preset=buildbot_linux,without_host_swift |
|
Trying something hideous, unless @eeckstein has any better ideas for the last failure? |
|
Is this just an experiment to see how far you get or do you really expect to get bootstrapping to work again? It's been a year since the CI switched over to only using a prebuilt Swift 5.8.1 compiler to build the trunk compiler, so I doubt you can get all those dependencies weeded out again. Even if you get a basic bootstrap C++-only compiler built again, it may no longer work to build the full compiler with swift-syntax. For example, I just successfully cross-compiled the trunk compiler for Android for the first time in nine months, and I initially tried working around a recent swift-driver issue on Unix platforms by disabling it and going back to the legacy C++ Driver. However, that would get the same tag of the prebuilt official linux toolchain for Fedora that I was using to cross-compile Only once I put in another workaround for the swift-driver issue and went back to swift-driver did that finally cross-compile, implying the swift-syntax build now depends on some new swift-driver flags that aren't in the legacy C++ Driver anymore, which is all you'll have in this bootstrap compiler too. Rather than fixing potentially dozens of bootstrap issues like this, I think it would be better to rip out the last remaining bootstrap support and make it easier to cross-compile and test the Swift stdlib and compiler for new platforms, which after all you've been warning people is the plan now for years on the forum. |
I'm trying to see whether we can build enough of a toolchain from just the C++ code to serve as a host toolchain to build the full compiler.
To be clear, I don't want to do the bootstrapping mode ever again. It's "use C++ to build a minimal host toolchain, use that as host tools to build the full compiler." If it doesn't work, fine, If it does work, we should consider keeping that around until...
Yes, that's the goal. We're not at that goal, and are in an unfortunate place where both paths are hard. I'm trying to determine whether we can resurrect the starting-from-C++ path and keep it around a little longer to bridge the gap until cross-compilation becomes easier. |
|
Okay, we timed out in testing, so... that's an improvement? |
Introduce various fixes to the build system, compiler, and standard library to enable building without Swift host tools, to make it possible to bootstrap a Swift compiler on a host that does not have Swift yet (without cross-compiling). The compiler built from only C++ doesn't need to have full functionality (and it doesn't---at least macros and embedded won't work), but it needs to have enough functionality to act as host tools for a full build of the toolchain.