<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
So, for example, you plan on implementing your own equivalent to the Clang AST matchers but for your Fortran AST?<br>
<br>
-Troy
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> on behalf of Stephen Scalpone via llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Sent:</b> Friday, March 1, 2019 4:13:10 PM<br>
<b>To:</b> Bruno Ricci; llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] RFC for f18+runtimes in LLVM</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">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" <llvm-dev-bounces@lists.llvm.org on behalf of llvm-dev@lists.llvm.org> 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>
llvm-dev@lists.llvm.org<br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">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>
_______________________________________________<br>
LLVM Developers mailing list<br>
llvm-dev@lists.llvm.org<br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div>
</span></font></div>
</body>
</html>