[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