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

[Sam McCall via cfe-dev]

Late to this conversation, though most my thoughts have been covered by
Richard and others already.
My perspective is mostly from the clang tools side and clangd in
particular, which tend to embed all major parts of clang/ (including Driver
and Frontend).

The consensus around generalizing/moving Driver, Diagnostics and not
Frontend sounds good.
It's important that we can still do the equivalent of today's
clang::createInvocationFromCommandLine without a flang dependency though.
I think this could be good for the code health of Driver in particular.

On Tue, Jun 9, 2020 at 5:14 PM Andrzej Warzynski via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 1a. Generalize SourceManager so that it's suitable for both Clang and Flang

1b. Move the updated SourceManager, together with SLocEntry,

I'm less sold on this. Clang's SourceManager has a *very complicated API*
for its conceptual job, to the point that understanding SourceLocations and
how to use them is a barrier comparable to understanding the C++ AST for
inexperienced tool developers. I've seen countless bugs introduced due to
this. Generalizing it to also deal with a (subtly? dramatically?) different
preprocessing model may concentrate complexity where we can't afford it.
This plan is different from Richard's suggestion of

> having a reusable template that can generate a data structure that the
> Clang and Flang SourceManagers can be implemented in terms of.

which seems less risky to me, but maybe more details on what
generalizations are needed would help.
(A lot of the complexity here is intrinsic to the C++ compilation model,
some is incidental, I'm not sure it makes much difference).

SourceLocation, FileManager, VFS

nit: VFS is already in support.

Thanks for laying all this out, working out how to factor this properly
seems important and useful for LLVM.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200610/c5778817/attachment.html>