Hmm, I'm not sure about this. I thought it was fine at first, but...

This isn't libcxx-private, at least according to: https://en.cppreference.com/w/cpp/header/version . For example, gcc's C++ stdlib has a <version> as well.

This means all sorts of software (boost for example: https://www.boost.org/doc/libs/1_74_0/boost/config/detail/select_stdlib_config.hpp ) may wish to include <version>, and while that might not be breaking now in anything we have currently, it may in the future-- as long as we're incorrectly searching header locations in the wrong order/precedence.

As a small consideration, I'm not sure what the expected stability of these paths are (include/c++/v1/version) and am worried if they change we'll miss it (as we likely propagate this fix forward in the future). This could be fixed, if a bit painfully, by including a check that the injected path indeed exists.

OTOH this is, of course, a problem we should try to fix! Can we do something at the wrapper level to provide the expected behavior here instead?
I would guess the reason we don't have this problem with gcc is because it already 'knows' where to find its C++ bits (where-as we build libcxx separately from clang and so have to point it to the right places via, -isystem or whichever).

The benefit is fixing this at the wrapper (or clang?) level would fix all (current and potential) include'ers of <version> instead of this instance. And possibly any other conflicts between user code/files and C++ standard library header names, as well (although 'version' is offhand probably the most likely to crop up in a source tree :)). Additionally, I think we want(ed) to try to separate gcc from libstdcxx (and other runtime libraries) to keep everything working the same way, but I don't know the status of that.

I guess this is a long way to say I'd prefer if we could fix this more completely, but other than the consideration mentioned above I suppose I don't know that there are significant drawbacks to modifying libcxx in the suggested way (don't see how this would break things really, for example).

cc @Mic92 for possible input on addressing this at the cc-wrapper level (thanks! ❤️).

From what I understand, the -I flag is by design allowed to override the system includes, so a change to the cc-wrapper would break that behaviour for all the libcxx includes, unless we move the to different path.

In ideal situation, upstream or us could patch all the software to not conflict with this include from C++20, and it might just happen over time if we just leave things as is. But then folks will be getting the compilation errors, and those kind of look weird.

Also, I wonder why we don't see this with libstdc++ yet.

Doesn't look like we need this at such a large scale. Should be fine to not implement.