[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D126907#3777088 <https://reviews.llvm.org/D126907#3777088>, @ldionne wrote:

> 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.

Yep, this is the case.  Just frustrating to be surprised by things like this as late in the process as I was, so I was a little grumpy above.  Unfortunately it seems like each of these cycles costs a month here :/

> 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