[libcxx-commits] [libcxx] [libc++] Stabilize transitive includes for C++23 (PR #134143)

[Louis Dionne via libcxx-commits]

ldionne wrote:

> > > I think the rationale makes sense, but I'm not actually sure the solution is the right one. Would keeping the public headers actually help with the breakages you've seen?
> > 
> > 
> > I think it would, as with all the other transitive includes breakages? You seem to imply that we'd want another solution, but I'm not certain I follow your thought here. Can you elaborate?
> 
> We're not including top-level headers anymore in most of places. Consider for example `<functional>`. The header provides `vector`, but `<vector>` isn't listed in the transitive includes of `<functional>` in C++23, since we only include `<__vector/vector.h>`. That means that if we managed to remove that dependency, the transitive includes test would be completely happy, even though we've probably broken some user by removing it. This change will make it less likely that we're breaking someone through granularizing non-granular headers, but that basically doesn't happen anymore anyways. We're more likely to move some code around and remove a dependency that way I think.

I see what you mean now, thanks for explaining. However, taking the `<functional>` example: `std::vector` must have been provided by `<functional>` pretty recently, no earlier than since we started splitting headers, right? Because if it was provided before then, the only way it would have been provided is via `#include <vector>`, and that would have been preserved through our transitive inclusion stability.

I do agree that what you describe is likely the bigger problem nowadays, and I do agree that keeping transitive public includes stable doesn't help that. However, we've come across breakage that would have been easily avoided by keeping the public transitive includes stable, so I'd like us to at least do that. The rationale is also consistent with us doing it for C++03 - C++20.

> Also, somewhat tangential, IMO we'll need to give users some way to get include-clean. Keeping this cruft around is a huge hit on compile times, and the transitive include test probably made things a lot worse, since we've never dropped any transitive includes, no matter how long they were actually in the library. #139855 seems related.

Thanks for the heads up on that PR. I have thought about this several times in the past, and it's good to see people actually working on it. I agree that with something like a compiler warning to get include-clean, we should re-have the whole discussion about transitive includes. I think it might be reasonable to start dropping transitive includes entirely if we had that tool (and perhaps an automatic fix-it tool). But in the absence of such a tool, I'd like us to at least try to keep stable what we can.

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