[libcxx-commits] [libcxx] [llvm] [libc++][C++03] Use `__cxx03/` headers in C++03 mode (PR #109002)

[Louis Dionne via libcxx-commits]

https://github.com/ldionne commented:

I want to record the discussion we just had about this patch.

As we make more progress on this project, we discover additional complexity that we need to handle. This was expected, however we didn't know what we were going to find. Anything that falls in the intersection of the C++03 headers and the new headers is where things can be difficult, such as:
- The configuration of the library via CMake (embodied by `__config_site`)
- The dylib, which must be shared by both sets of headers

This patch makes it clear that handling the configuration side of things is non-trivial and can lead to very confusing situations. For example, we need to shim the `__config_site` header to account for changes from `#if defined(_LIBCPP_FOO)` to `#if _LIBCPP_FOO` in the past couple of months. IMO that's extremely confusing and not a state that we can live with for a prolonged period of time, since it'll lead to bugs. The same goes for e.g. the `__locale_base_api` refactoring where we are changing some symbol names on Windows. Those are changes we'd need to backport to the C++03 headers in order for the codebase to stay maintainable.

We discussed another approach where we instead fork individual headers as we decide that we want to drop C++03 headers. For example, create `__cxx03/vector` only when we actually want to fork its implementation to take advantage of non-03 features. Seeing all the complexity introduced by the approach pursued here, that's the approach I would like for us to try instead. @philnik777 disagrees and thinks we'll end up in a similar place at the end of the day (I'm not sure I agree but that's a reasonable opinion to have).

Since the approach taken in this patch is still something we can back out of, I am okay with moving forward with it experimentally despite having significant concerns. If we don't manage to simplify the intersection between the old and the new headers, I don't think this is something we can ever ship. But if we do, then perhaps this approach is fine in the end. Since the only way to know for sure is to keep making progress on this approach, I'm fine with moving forward with this.

The subsequent patches should aim to simplify the old/new headers integration and those can be iterated upon in a separate branch without introducing too much risk for merge conflicts.

I'd like to see this again with comments resolved before this gets merged.

I feel a bit bad for being so critical of this approach, but I think it was unavoidable that we'd find out difficulties with any approach trying to do this non-trivial change. We'll have to figure out whether these difficulties can be overcome or if they actually outweigh the benefits provided by the split.

https://github.com/llvm/llvm-project/pull/109002