[PATCH] D105439: [clang] protects users from relying on libc++ detail headers

[Christopher Di Bella via Phabricator via cfe-commits]

cjdb added a comment.

In D105439#2858291 <https://reviews.llvm.org/D105439#2858291>, @Quuxplusone wrote:

> Step 1 should be to find out if this is even a problem at all. For example, try using one of these tools to compile a C++ program against GNU libstdc++, or against a library like range-v3, both of which already uses many small detail headers. Is the tool's output confusing or incorrect for //those// libraries? Only if it's actually a problem, should Clang itself try to solve problems with those tool/library combos by adding special-case code into the Clang codebase.

I didn't say that any tool's output is "confusing or incorrect". I said that tooling will accidentally include libc++'s detail headers, which is undesirable, as it is non-portable. You've also disregarded my statement about Hyrum's law, which points out that users will come to rely on `<__algorithm/find.h>` with or **without** tooling. Tooling only accelerates the problem of including detail headers.

In D105439#2858295 <https://reviews.llvm.org/D105439#2858295>, @lebedev.ri wrote:

> Why not solve this in the headers themselves?
> Just `#error` in implementation header if some macro isn't defined, and define said macro in parent header before including implementation detail headers?

Do you mean like this?

  #define _LIBCXX_DETAIL_HEADERS_ALLOWED
  
  #include <__algorithm/find.h>
  ...
  
  #undef _LIBCXX_DETAIL_HEADERS_ALLOWED

That would cover headers too (very good), but I'm not sure how it will play with Clang's modules.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105439