[libcxx-commits] [PATCH] D68480: Implementation of C++20's P1135R6 for libcxx

[JF Bastien via Phabricator via libcxx-commits]

jfb added a comment.

In D68480#1894037 <https://reviews.llvm.org/D68480#1894037>, @ldionne wrote:

> In D68480#1893987 <https://reviews.llvm.org/D68480#1893987>, @jfb wrote:
>
> > In D68480#1893953 <https://reviews.llvm.org/D68480#1893953>, @leonardchan wrote:
> >
> > > Hi, a bisect shows that this patch seems to cause time.h to not be found for us:
> > >
> > > [...]
> > >
> > > Do you know if this is a known or unintended side effect of this patch? I don't think we changed anything on our side that would've caused this.
> > >
> > > Builder: https://ci.chromium.org/p/fuchsia/builders/ci/clang_toolchain.fuchsia-x64-debug-subbuild/b8887404211928925456?
> >
> >
> > Is zircon freestanding, and not providing `chrono` (which then includes `time.h`)? That would explain the issue, we'd need to fix freestanding `atomic` by not exposing time-related stuff if `time.h` ins't available.
>
>
> So, actually, I think we need to have a discussion about the support of Freestanding in libc++. We should either implement it properly and have testers for it, or stop pretending that we do. Right now all I see us doing is adding complexity to our code to fix stuff that breaks on user configurations we don't know about, understand or test. As someone who has to maintain the code with that complexity, this concerns me.
>
> And I do care about Freestanding -- I think it's important and we should support it. But I also think that we should not do it halfway like right now. In the current state of things, I literally have no way to ensure that we won't break that configuration again tomorrow. @leonardchan @phosek Is there a way that you could add a libc++ builder that runs freestanding?


Agreed, it seems like we want to figure out what individual freestanding subsets can "carve out" of regular C++, and how to do so cleanly. "time" seems like an easy thing to carve out, but it shouldn't just be done here, it should be part of the configuration header, applied consistently through libc++, and extensively tested. Ideally it wouldn't just be a builder: you'd have a directory which tests freestanding configuration options (i.e. "can I include atomic without time support?").


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68480