[llvm-dev] RFC for f18+runtimes in LLVM

[Chandler Carruth via llvm-dev]

On Mon, Feb 25, 2019 at 10:06 AM Stephen Scalpone via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> * The current f18 code will be committed to the new LLVM subproject.  The
> f18 code is a set of libraries that implements the Fortran compiler.
>

Awesome. This is an important aspect of the design of LLVM projects IMO ->
they build their functionality primarily as re-usable libraries, and then
expose that in useful command line utilities.


> The f18 compiler source code complies with most of LLVM's coding
> guidelines; however, the code uses several C++17 features.  We've
> documented our use of C++17 here:
>
>
>
>   https://github.com/flang-compiler/f18/blob/master/documentation/C++17.md
>
>
>
> In particular, the parse tree and the lowered forms of expressions and
> variables are defined in terms of C++17 std::variant. Most of the
> compiler uses C++17 std::visit to walk these data structures.
>
>
>
> It’s possible to reimplement the most important functionality of
> std:variant as a subset class, say llvm:variant; however, variant gets
> its power from the C++17 features generic lambdas and parameter pack
> expansion on “using”.  Without these C++17 features, use of variant would
> be impractical.
>
>
>
> Our thinking when we started was that llvm would adopt C++17 before
> mid-2020, which lines up with our projected completion date. If we were to
> adopt C++11 or C++14, we would likely create substitutes for these classes,
> certainly at a cost of calendar time and perhaps type safety and notational
> convenience.  One of our principles is to take advantage of the standard
> library as much as possible, so casual readers will better understand our
> code and so we avoid the time and bugs associated with writing class
> libraries.
>
>
>
> Our request would be to get a waiver for the C++11 requirement based on
> the fact that we're skating to where the puck will be.  In the meantime,
> because F18 only exists as a stand-alone program, early adopters would
> still have a useful parser and analyzer for Fortran.
>

Hold on, either it is a collection of libraries or it is a stand-alone
program. It can't really be both?

Generally, I think the idea that diverging from the rest of the project
here is low-cost for a subproject isn't supported by experience with other
projects.

Notably, it has a strong tendancy to create tension. You want some ADT or
support library in LLVM to work well with your C++17 code. But it is C++11.
Every time this has been done in the past, the result has been that
generically useful tools and libraries get added to the subproject rather
than to LLVM as a whole.

So FWIW, I'd be really opposed to this. Instead, I think that F18 should
have rich libraries, and develop them exactly the same way as the rest of
LLVM.

We're getting close to switching to C++14, so maybe due to timing, you
could merge F18 when that happens?

Ultimately, I think you either need to raise the LLVM base language version
or lower the F18 one so that they match when merged IMO. Anything else I
think will hamper integration with the larger project.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190225/5179194d/attachment.html>