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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
