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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
