Refactoring Clang - could this benefit Swift?

I'm new to this community so first of all, Hi everyone!

I am a member of the Fortran Team at Arm and would like to draw your attention to the RFC that our team has sent today to llvm-dev/cfe-dev/flang-dev: [llvm-dev] [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM

TL;DR We would like to move the bits of Clang that could be re-used by other frontends to LLVM. Is this something that Swift could benefit from? Would anyone like to get involved? Your input (either here or, preferably, on llvm-dev) would be much appreciated!

Thank you,
-Andrzej

4 Likes

MHO, not some sort of policy.

Other than the time spent updating for the upstream refactoring (which, personally, I don’t think should stop you—but maybe see how much you can mitigate it?), I don’t think this would make much difference to the Swift compiler either way.

Swift needs to embed and use much of clang—the preprocessor, parser, AST loader, Sema, and I think some of IRGen too—for our C-family interop features. We also use some of the clang components you're thinking about moving in our diagnostics and other infrastructure, but moving these to LLVM wouldn't free us of our clang dependency, so we're not really itching to see it happen.

In fact, we actually don't use some of the things you're considering moving—we have our own equivalent to SourceLocation because clang's is overengineered for a language without textual includes, and our compilation model is too different from C's to use much of clang's driver. (We're actually working on a new llbuild-based driver implemented in Swift.)

So I don’t think we would gain from the refactoring you're suggesting, but if it makes sense for other LLVM projects, we're certainly not opposed. We’ll have to adjust, but adjusting to upstream refactoring is the cost of doing business in the LLVM ecosystem.

7 Likes

Thanks for your feedback, much appreciated!

Well put! :)