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

[Eli Friedman via llvm-dev]

> -----Original Message-----
> From: cfe-dev <cfe-dev-bounces at lists.llvm.org> On Behalf Of Robinson, Paul
> via cfe-dev
> Sent: Tuesday, June 2, 2020 6:43 AM
> To: Andrzej Warzynski <andrzej.warzynski at arm.com>; llvm-
> dev at lists.llvm.org; flang-dev at lists.llvm.org; 'cfe-dev at lists.llvm.org' <cfe-
> dev at lists.llvm.org>
> Subject: [EXT] Re: [cfe-dev] [RFC] Refactor Clang: move
> frontend/driver/diagnostics code to LLVM
>
> > 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.

Separate from clang, LLVM itself actually has its own infrastructure for source locations and diagnostics, which is used by various tools that parse text.  See llvm/Support/SourceMgr.h.  The reason this was implemented separately is that clang's infrastructure is overly complicated for most uses.  One, it's designed to support rich source locations out of C macro expansions.  Two, there's a bunch of infrastructure for managing the diagnostics themselves: warning levels, warning groups, etc.  If you don't need either of those, the clang infrastructure is overkill, and harder to use.

It's possible that flang's needs are similar enough to clang that it actually wants all the clang infrastructure.  But I can't imagine anyone else would want to use it over simpler alternatives.

Mapping source locations from LLVM IR back to the frontend is a separate issue, which I don't think is related to this.  We probably don't want to tie LLVM IR to any specific frontend representation of source code, and there isn't really any need.  See, for example, http://llvm.org/docs/LangRef.html#inline-asm-metadata .

-Eli