[libcxx-dev] Compiler support in libc++

Wed Mar 3 20:28:03 PST 2021

Strongly in favour of this :-)

On Mon, 1 Mar 2021 at 17:54, Zoe Carver via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:

> As a libc++ contributor, I am strongly in favor of this. I'd like to
> re-iterate three main points:
>
>    1. Currently, we are telling users that libc++ supports Clang 3.5 (for
>    example) when there is no proof of that. We are basically guessing
>    (actually, we're not even guessing; if I had to guess, I'd say that Clang
>    3.5 probably won't work).
>    2. This will make the QoI way better. Bugs are hidden in macros when
>    we have to support many/old compilers. We can also remove a lot of dead
>    code, which will make it easier to reason about the implementation logic.
>    3. Users of old compilers can download old versions of libc++ (in the
>    uncommon case when this is required) by simply heading to
>    https://releases.llvm.org/download.html.
>
>
> Thanks for pushing this forward, Louis!
>
> On Mon, Mar 1, 2021 at 9:40 AM Louis Dionne via libcxx-dev <
> libcxx-dev at lists.llvm.org> 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.
>>
>> _______________________________________________
>> libcxx-dev mailing list
>> libcxx-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>>
> _______________________________________________
> 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/libcxx-dev/attachments/20210303/52ce2737/attachment-0001.html>