[llvm-dev] Compiler support in libc++

[Mark de Wever via llvm-dev]

As a libc++ contributor a +1

Cheers,
Mark de Wever

On Mon, Mar 01, 2021 at 12:40:36PM -0500, Louis Dionne via llvm-dev wrote:
> 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.

> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev