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 Rust could benefit from? Would anyone like to get involved? Your input (either here or, preferably, on llvm-dev) would be much appreciated!
rustc already doesn't use any parts of (lib)clang. It depends only on libllvm. I didn't read the entire RFC since it's quite long, but it's not clear to me what the benefit is for rustc to reuse parts of clang. Also, rustc is experimenting with other backends besides LLVM such as cranelift and miri, so I don't think we'd want to introduce additional dependencies on LLVM.
@jethrogb I should clarify that for this refactoring we focus on the driver. We want to refactor things like Diagnostics & SourceLocation (among other things), which are used by both the driver and the frontend. This refactoring is a prerequisite for any actual frontend code (i.e. parser, sema, AST) being shared between different frontends.
From what you are saying this wouldn't really change much from the perspective of Rust. I've not worked with Rust so I'm not familiar with the architecture. I was hoping that this could fall into: "LLVM/Clang - nice to have".
Thanks for your feedback and apologies for the confusion regarding frontend vs driver!
This could help a great deal in a few different areas.
I don't think we're at all likely to use things like the diagnostic and location framework; we have such a framework already, and I don't think we'd want to tie ourselves to LLVM's.
We've talked about the idea of having better C integration/support, and having first-class C parsing would help; I'd love to see that.
Also, I'd be interested in the aspects of the driver that parse C command-line options in a manner compatible with clang (and somewhat compatible with gcc), and that handle include paths and other aspects of C.