<div dir="ltr"><div dir="ltr">Late to this conversation, though most my thoughts have been covered by Richard and others already.<div>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).</div><div> </div><div>The consensus around generalizing/moving Driver, Diagnostics and not Frontend sounds good.</div><div>It's important that we can still do the equivalent of today's clang::createInvocationFromCommandLine without a flang dependency though.</div><div>I think this could be good for the code health of Driver in particular.</div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 9, 2020 at 5:14 PM Andrzej Warzynski via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
1a. Generalize SourceManager so that it's suitable for both Clang and Flang</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
1b. Move the updated SourceManager, together with SLocEntry,</blockquote><div><div>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.</div><div>This plan is different from Richard's suggestion of</div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">having a reusable template that can generate a data structure that the Clang and Flang SourceManagers can be implemented in terms of.</blockquote><div>which seems less risky to me, but maybe more details on what generalizations are needed would help. </div></div><div class="gmail_quote"><div><div>(A lot of the complexity here is intrinsic to the C++ compilation model, some is incidental, I'm not sure it makes much difference).</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
SourceLocation, FileManager, VFS</blockquote><div>nit: VFS is already in support.</div><div><br></div><div>Thanks for laying all this out, working out how to factor this properly seems important and useful for LLVM.</div></div></div>