For those supporting other platforms if you would like to test against the llvm-project:stable/20230725 merge before it lands please check out the following branches:
Swift will have an automerger from main into rebranch to keep the branch in sync.
Branch Detail
Swift rebranch was created from next on July 25th 2023.
LLVM Project stable/20230725 were created from next on July 25th 2023, and aligns with llvm/llvm-project:release/17.x branch.
we are planning on perform the merge on Oct 17th 2023.
Swift does use mainline LLVM. We just for ease of development compile Swift against a snapshot of that LLVM. Every bit or so, we choose a new snapshot from upstream LLVM and update Swift all at once to compile against this newer LLVM.
The reason we do this is that when Swift was originally started we attempted to work against ToT LLVM and found that we were spending a lot of time just updating Swift against upstream LLVM changes which was very disruptive to normal development. This is compounded by LLVM's policy that if something in tree breaks something out of tree, then it is not the responsibility of LLVM developer who made the in tree change to update the out of tree project.
Swift needs its own LLVM probably for the same reason Rust needs its own LLVM. Before a patch lands upstream one needs to iterate on it in isolation in a specific project first.
Sometimes changes land in a future version of LLVM that hasn't been adopted yet, which means you have to cherry-pick changes to your own fork and continue using that until upstream LLVM version with that patch is ready for adoption. And usually by that point many more changes have landed upstream that are needed here and now. Due to the size of these projects they can rarely if ever converge to a single codebase without any forks.
It is pretty small though IIRC. Ideally those would all be upstreamed. The point is that overall, it lets the two projects proceed at their own pace in a way that isn't disruptive.