[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

Louis Dionne via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Sep 8 07:25:08 PDT 2022


ldionne added a comment.

In D126907#3746477 <https://reviews.llvm.org/D126907#3746477>, @Mordante wrote:

> Unfortunately there are a lot of different options and combination of options to test libc++.
> So it's indeed not possible to test all options with once check-cxx invocation.

This ^. We could include all the libc++ configurations in a single `check-cxx` invokation, but the tests would run for like 70 hours on most machines. Instead, we test different configurations in different CI jobs.

In D126907#3777056 <https://reviews.llvm.org/D126907#3777056>, @erichkeane wrote:

> Still WIP, but uploading to show that I'm still on this :/
>
> The two modules related issues from libcxx are now fixed (as reported by @Mordante), and that configuration builds and passes all tests with MOST of this change.
>
> HOWEVER, the first of two fixes for @wlei messes up how constraint expressions on class templates are compared, so the result is ~800 additional libcxx failures.  I'm still working through that.

Just to make sure we're on the same page, I assume most of those issues are things that would have been encountered in user code otherwise and filed as bugs. So in a way, I think libc++ is simply acting like some kind of early-in-the-loop pre-release testing. This is similar to what some other open-source projects like Chrome do -- they build from trunk often and will report actual issues to us early. I do get why it can be annoying and disruptive to landing patches sometimes, though.

Concretely, what we could do is probably add `LLVM_ENABLE_RUNTIMES=libcxx` to the Clang pre-commit CI that already runs. That would catch some (but of course not all) issues. In particular, that should catch issues that would otherwise immediately break the libc++ "Bootstrapping build" CI job. For other issues (like an arbitrary combination of `-std=c++xy -fmodules -fno-rtti`), I think we can only rely on slower feedback when libc++ updates the nightly version of Clang that we use in our CI (which would act like a super-early adopter from the POV of Clang at that point).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126907/new/

https://reviews.llvm.org/D126907



More information about the cfe-commits mailing list