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

[Chris Lattner via cfe-dev]

On Jun 2, 2020, at 12:51 PM, Eli Friedman via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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 <http://llvm.org/docs/LangRef.html#inline-asm-metadata> .

I think there is room for both of these in the LLVM world: I think about SourceMgr as the right infra to use for small tools (e.g. tblgen, the .ll/mlir parsers, etc) and something like the clang diagnostic infra as being the right thing for full compilers like Swift (or flang, clang obviously).  The warning groups and other things are important for anything with real users, and concerns like multiple dialects and source compatibility over time.

I think it would be great to generalize Clang’s infra a bit if it can be reasonably done without hurting clang.  Flang adopting it would be a great test case.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200602/3cf18ce1/attachment.html>