[llvm-dev] [libcxx-dev] Compiler support in libc++

Mon Mar 1 10:12:35 PST 2021

As a (rare) stl contributor I am also strongly in favor of the proposal.

I greatly reduces the maintenance burden for us.

--Michael

Am Mo., 1. März 2021 um 18:40 Uhr schrieb Louis Dionne via libcxx-dev <
libcxx-dev at lists.llvm.org>:

> Dear LLVM community,
>
> I’ve wanted to address the topic of which compilers are supported by
> libc++ for a long time. LLVM documents that it supports GCC >= 5, Clang >=
> 3.5 and other fairly old compilers. I think this makes a lot of sense for
> codebases like LLVM and Clang, since it means you can bootstrap a compiler
> with your system compiler in many cases. It’s also fairly easy to enforce
> that, since you just have to code in a supported subset of C++.
>
> However, for a library like libc++, things are a bit different. By its
> very nature, libc++ needs to rely on a recent compiler in order to
> implement most recent library features. Not being able to rely on a recent
> compiler leads to problems:
>
>    -
>
>    Adding new features is significantly more complicated because we need
>    to implement them conditionally on compiler support, not just on support
>    for a C++ Standard. There can also be interactions between what compiler
>    the library is built with and what compiler the headers are used with.
>    -
>
>    We accumulate technical debt around the code base. Some of these
>    #ifdef code paths are not in use anymore, others don’t compile anymore or
>    they contain bugs.
>    -
>
>    It creates a false sense of support: people think they can use a
>    libc++ built with e.g. Clang 3.5, but in reality doing so is a terrible
>    idea. The library might not contain runtime support for features that will
>    be advertised as available by the headers (the char8_t RTTI and the
>    upcoming support for <format> come to mind). Those are serious ABI issues
>    that you’ll only notice when trying to use the feature.
>
>
> I think it’s important to stress that the current state of things is that
> we don’t *actually* support much older compilers - the documentation claims
> we do, but that is misleading. While things may happen to work on older
> compilers, I wouldn’t recommend relying on that for anything serious, since
> it’s mostly untested.
>
> Furthermore, the actual value of supporting old compilers isn’t obvious.
> Indeed, the best way of building libc++ is to bootstrap Clang and then
> build libc++ with it, which is easily achieved with the LLVM Runtimes
> build. Of course, we also support different shipping mechanisms (including
> non-Clang compilers), but in all cases it should be reasonable to expect
> that someone building libc++ at the tip is able to do so using a recent
> compiler.
>
> For all these reasons, I think we must adjust the official support policy
> we currently document. Concretely, the following modified policy solves the
> issues I mentioned above and makes it so that the stated support reflects
> the reality of what we truly support:
>
>    -
>
>    At any given point in time, libc++ supports back to the latest
>    released version of Clang. For example, if the latest major release of
>    Clang is 14, libc++ (on main) supports Clang 14. When Clang 15 is released
>    (and libc++ 15 with it), libc++ (on main) is free to assume Clang 15. As a
>    result, any released libc++ will always support the previously (and the
>    currently) released Clang, with the support window moving as newer Clangs
>    are released.
>    -
>
>    We support the latest major release of GCC, as advertised on
>    https://gcc.gnu.org/releases.html.
>    -
>
>    We support the latest major release of AppleClang.
>
>
> The above policy is reasonable from libc++’s perspective, and it also
> reflects what we test on a regular basis with the CI. Furthermore,
> supporting up to the last release instead of requiring a trunk compiler
> (like MSVC’s STL and libstdc++) gives vendors with alternate delivery
> vehicles approximately 6 months to update their compiler if they want to
> jump on the next release of libc++, which I think is an important property
> to retain.
>
> This message is both a heads up about the current state of things, an
> explanation of where we (the libc++ contributors) want to end up, and an
> invitation to have a discussion with the rest of the community.
>
> I propose that we maintain our current level of support for older
> compilers (i.e. keep things roughly building) until the next LLVM release,
> after which the above policy would become official and libc++ development
> would be allowed to assume a compiler as documented above. That would give
> approximately 6 months (from now to the next release) for people managing
> build bots to migrate to the Runtimes build, and approximately 6 months
> (from the next release to the next-next release) for external users to
> adjust to this policy if needed.
>
> Thanks,
>
> Louis
>
> P.S.: There is no mention of other compilers besides Clang, AppleClang and
> GCC above. That’s because no other compiler is tested on a regular basis,
> so the status of support for other compilers is unknown. If you’d like to
> add official support for a new compiler, I’ll be happy to help you set up
> the required testing.
>
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210301/bdefbe2c/attachment.html>