[cfe-dev] [llvm-dev] [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM

[Hanna Kruppe via cfe-dev]

On Tue, 2 Jun 2020 at 18:05, Andrzej Warzynski via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
>
> On 02/06/2020 14:43, Robinson, Paul wrote:
>
> >
> > Flang would obviously be the in-tree beneficiary; are there downstream
> > projects that would like this change?  I don't mean speculatively, have
> > you tried asking around (Julia and Rust pop to mind)?  Interested
> > downstream consumers would provide a bit more motivation for such a
> > widespread refactoring.
>
> That's a good suggestion, thank you! I've just posted the following:
>
> * Julia:
> https://discourse.julialang.org/t/refactoring-clang-could-this-benefit-julia/40621)
> * Rust:
> https://internals.rust-lang.org/t/refactoring-clang-could-this-benefit-rust/12479

I can't speak for other Rust compiler developers, but personally, I
doubt that we'll find a use for such a library. Using *any* C++
library for such a significant purpose in rustc is a hard sell, for
social as well as technical reasons. We use LLVM for optimizations and
codegen because it's worth the trouble, but for things where we
already have a working solution of our own, the downsides of switching
to something different are probably overwhelming. Some examples:

* Most contributors to Rust know Rust better than C++, if they are
proficient in it at all. Even people who don't directly contribute to
the component in question may need to read the code from time to time.

* Using C++ libraries from Rust is generally possible but relatively
involved (bindings must be developed and maintained, subtle bugs in
them are likely). If templates are involved or virtual methods need to
be overriden, lots of actual logic (and not just glue code for
bindings) may have to be written in C++, too, and this might in turn
require even more Rust/C++ bindings.

* As LLVM libraries have different development processes, tools, and
communities, making a change to LLVM libraries it is harder for those
accustomed to the ways things are done in the Rust project.

In addition, there may be some serious differences in functional
requirements.For example, Rust has hygienic macros and this is
implemented by associating extra hygiene-related data to every single
source code span. The specific representation of source locations also
interacts with the way incremental compilation is done in rustc, and
likewise for diagnostics (e.g., need to record and replay diagnostics
even if the passes that emitted them are skipped because the function
wasn't modified since the last build). I haven't thought deeply about
what porting these and other aspects to Clang-derived libraries would
involve, but at first glance it seems quite difficult.

All of this sounds very pessimistic, but to be clear, I think it's
great that this question was raised! More code reuse across frontends
would be great, it just seems like it wasn't meant to be in this
specific case.

Thanks,
Hanna


> * Swift:
> https://forums.swift.org/t/refactoring-clang-could-this-benefit-swift/37151
>
> Hopefully somebody from those communities will comment here. If not, I
> will summarise any discussion happening outside llvm-dev in a separate
> message. Please let me know if you think that the above list is incomplete!
>
> -Andrzej
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev