<div dir="auto"><div>Hi Steve, </div><div dir="auto"><br></div><div dir="auto">This seems reasonable to me. I didn't think it would be possible to reuse the preprocessor or the AST for exactly the same reason you mention (similar from far enough but lots of differences in the details). Thank you for you answer. </div><div dir="auto"><br></div><div dir="auto">Bruno<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, 1 Mar 2019, 22:13 Stephen Scalpone, <<a href="mailto:sscalpone@nvidia.com">sscalpone@nvidia.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Bruno, Troy,<br>
<br>
We looked early on at reusing the preprocessor and other source-file utilities from clang.  It turns out that while preprocessors look similar on the surface, preprocessors are deeply integrated with their source language and take into account many language syntax rules.  In the f18 documentation we have two documents that dive into more details about the differences between C and Fortran and the nuances of the preprocessor.<br>
<br>
We thought we might be able to reuse the clang diagnostic infrastructure, but upon looking at the code we saw a lot of very specific C/C++ information in that code, which seems very natural to want to keep as much semantic information as possible for error messages.  In the end, it seemed impractical to try to map Fortran entities to C/C++ objects just for the diagnostic infrastructure.  <br>
<br>
 - Steve<br>
<br>
On 3/1/19, 9:47 AM, "llvm-dev on behalf of Bruno Ricci via llvm-dev" <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev-bounces@lists.llvm.org</a> on behalf of <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a>> wrote:<br>
<br>
<br>
<br>
    On 01/03/2019 17:26, Troy Johnson via llvm-dev wrote:<br>
    > This RFC started a good discussion and I’d like to hear responses from its author<br>
    > to all of the points that have been made so far.<br>
    > <br>
    >  <br>
    > <br>
    > FWIW, I’m also in favor of reusing as much from Clang as practical.  In fact, with> the combined repo now, it might make sense to factor out some common front end code<br>
    > that both a Clang and any Flang (f18 or Fort) would use, for maintainability as well<br>
    > as to avoid the perceived strangeness of a Fortran front end relying on a C front end.<br>
<br>
    What part of the frontend do you think could be shared ? At least the following seems<br>
    to be re-usable:<br>
<br>
    - The diagnostics infrastructure<br>
    - IdentifierTable<br>
    - The file manager and source location infrastructure<br>
<br>
    Bruno<br>
    _______________________________________________<br>
    LLVM Developers mailing list<br>
    <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
    <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
<br>
<br>
-----------------------------------------------------------------------------------<br>
This email message is for the sole use of the intended recipient(s) and may contain<br>
confidential information.  Any unauthorized review, use, disclosure or distribution<br>
is prohibited.  If you are not the intended recipient, please contact the sender by<br>
reply email and destroy all copies of the original message.<br>
-----------------------------------------------------------------------------------<br>
</blockquote></div></div></div>