I’m very excited to have NVIDIA collaborate on libc++. It’s worth supporting your weirdo macro hack as a transitional tool.
I’m especially interested in working on freestanding in clang / libc++, bringing the good parts of it from the current C++ standard, and working with you and other on the Committee to make C++23 freestanding actually nice (Ben Craig has been working on wg21.link/P0829R3 <http://wg21.link/P0829R3>). I hope that we can experiment on what’s “nice” in clang / libc++ in the next few months.
One design constraint around freestanding: I want to make sure that clang can keep supporting other STL implementations.
I’d like to understand if we can have a different ABI for freestanding, given that it’s not supported in libc++ today. This might be an opportunity to fix some mistakes.
On “freestanding” macro, clang does the following today:
Otherwise, clang’s lib/Headers do some stuff with HOSTED as well, which might interfere with freestanding.
Good header hygiene indeed seems necessary, especially for <algorithm>. Louis mentioned that he was interested in looking into this.
Louis did a survey and found the following:
Freestanding in the current C++20 draft requires the following headers:
Of those headers, I think the following are easy to provide with minimal changes to libc++ and without having to ship a libc++ shared object (or compiler-rt), and they use the following parts of the C Standard Library:
<cfloat> : float.h
<limits> : stddef.h
As a result, I think the following are low-hanging fruit that do not require any runtime support AFAICT:
Other things we might be able to throw in with minimal effort:
Other things that we SHOULD be able to have, but that would require refactoring in libc++ (and most of them are not part of the current freestanding):
most if not all of <functional>
most of <algorithm>
lock-free parts of <atomic>