[llvm-dev] [cfe-dev] [RFC] Refactor Clang: move frontend/driver/diagnostics code to LLVM
Robinson, Paul via llvm-dev
llvm-dev at lists.llvm.org
Tue Jun 2 06:43:14 PDT 2020
> 1. All the machinery related to Diagnostics & SourceLocation.
>
> This is currently part of libclangBasic [4] and is used in _many_ places
> in Clang. The official documentation [5] suggests that this could be
> re-used for non-C-based languages. In particular, we feel that It would
> make a lot of sense for Flang to use it. Also, separating Clang's
> driver/frontend code and the diagnostics would require a lot of
> refactoring for no real benefit (and we feel that Flang should re-use
> Clang's driver/frontend code, see below). This dependency is used in
> many places, so moving it to LLVM will require a lot of (mostly)
> mechanical changes. We can't see an obvious way to split it into smaller
> chunks (see also below where we discuss the impact).
This totally makes sense to me. It has been a couple of decades but I
remember working with the OpenVMS GEM compiler system, and it had all
the source-management stuff in the equivalent of an LLVM library for
use by all front-ends. A consistent view of source coordinates across
the front-end and back-end was nice to have; I don't think moving the
Clang notion into an LLVM library gets us there, but it's a step in a
direction that I like.
I can imagine that some of the driver stuff would also be reusable,
but I don't have any direct experience to draw on there.
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.
--paulr
More information about the llvm-dev
mailing list