Could a Swift compiler and corelibs linked statically with Musl, libc++, curl, and BoringSSL become a bootstrapping solution for Gentoo, and any Linux distribution using a recent kernel in general?
Last time I tried to build Swift on Alpine, the only blocker was the sub-megabyte default stack size of Musl that could be worked around patching ELF binaries, but it did work in the end (I didn't run the compiler or corelibs/SwiftPM test suites though).
While we're at it, how would folks feel about bumping the minimum CMake version to 3.26? If we're adding more Swift to the compiler, having the mixed-source Swift + C/C++ libraries would mean better integration with the project as a whole instead of isolated Swift clumps. There are some other benefits too, but that would make the story a bit more cohesive.
I'd say jump to 3.28. So far 3.29 and 3.30 have been problematic with Swift code. But if we are jumping, we might as jump as far as we can 
Absolutely — though not insurmountable either:
default/linux/amd64/23.0/desktop/plasma) that can be relied on for base minimum versionsThat's to say that you don't necessarily need to anticipate what's on an existing Gentoo system because an ebuild can define what it needs from a target system, and it's possible to pick relatively reasonable expectations that would be easy to meet.
This is certainly possible, though might be overkill given Swift's specific dependencies: AFAIK, Swift doesn't necessarily need bleeding-edge versions of its dependencies, and most of those dependencies' ABIs are unlikely to change, right? (i.e., specifying major version ranges of dependencies could very well be enough)
Theoretically, sure! I have no experience with getting Swift to build statically-linked, but if it's possible, it'd be really interesting to explore. Even more so if we could get a very pared-down version of the compiler containing effectively only what's necessary to bootstrap the first stage in the process... (e.g., you wouldn't need curl, or BoringSSL, or libxml2, or...)
No complaints about this here. 3.28 is the lowest version currently available in the Gentoo package tree (and it works just fine to build 5.10.1)
@Douglas_Gregor one thing that is a concern is ABI stability. If Swift is included in the compiler (which it currently is), and there is no ABI stability, we cannot safely use the previous runtime to run the new compiler. Would we have some sort of ban on ABI breaking changes without a compatibility window?
@Douglas_Gregor Now that Swift 6 has shipped and these requirements are in place, is there any documentation that describes what we should expect in terms of the bootstrapping process we've discussed here?
I ask because of some exploration in this thread:
tl;dr: building Swift 6.0.1 using Swift 5.10.1 and the lld linker leads to a broken lldb/repl; building Swift 6.0.1 using Swift 6.0.1 and the lld linker leads to a working lldb/repl.
I suspect that this is an unintentional bug, but it's also entirely possible that my expectations are misplaced: I'm trying to build a Swift 6.0.1 compiler using Swift 5.10.1 all in one go, but maybe that's not intended to be supported, and I need to use Swift 5.10.1 to bootstrap a minimal 6.0.1 compiler, then use that to build the full 6.0.1 compiler?
I don't know if any concrete decisions have been made to support (or not support) this build process, but it'd be great to figure out what guarantees we make/want to make about how Swift should be built going forward.
I believe that dropping support for full bootstrapping (where you start with just a C++ compiler) too soon will hurt Swift. In particular, bringing Swift to new platforms will become much more onerous. While people who are employed by corporations and are paid for their efforts will jump through the newly added extra hoops, enthusiasts who have two spare hours on a Sunday will be forced to give up. And now is the time for Swift to be spreading.
Full bootstrapping (utils/build-script --bootstrapping bootstrapping) is unfortunately broken in Swift 6.0.2. The error message I get is:
ninja: error: 'stdlib/public/core/SwiftMacros', needed by 'bootstrapping0/stdlib/public/core/FREEBSD/aarch64/Swift.o', missing and no known rule to make it
If we are going to intentionally break full bootstrapping in a future release, let's have one final version of Swift where it is properly supported. Let's restore it to a fully working state and release it in 6.0.3 or 6.1.
Finally, I think that the Platform Steering Group should be consulted before any decision is made.
This is already done — Swift 5.10 is already that last release series where bootstrapping is fully supported. To the best of my knowledge, Swift 6 has never supported bootstrapping, because the compiler pipeline is focused on the Swift-based driver. This isn't something that could be reasonably "temporarily" undone for a release of Swift 6.
I think at this stage, it would make sense to rip out mentions of bootstrapping from the build system, to make this more obviously official (and document this more explicitly to make it clear what the expected process should be like).
With some hacks I managed to get Swift 6.0.2 to bootstrap. The resulting compiler didn't support macros but this might be because of the crudeness of my hacks.