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

cjdb added a comment. In D105439#2874805 , @cjdb wrote: > In D105439#2874733 , @lebedev.ri > wrote: > >> In D105439#2874706 , @ldionne >> wrote: >> >>> I'm not entirely

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

cjdb added a comment. In D105439#2874733 , @lebedev.ri wrote: > In D105439#2874706 , @ldionne wrote: > >> I'm not entirely sure I understand the purpose of this patch. So the idea is >> that let's say a tool sug

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

cjdb added a comment. In D105439#2874706 , @ldionne wrote: > I'm not entirely sure I understand the purpose of this patch. So the idea is > that let's say a tool suggests including `<__algorithm/find.h>` to get the > definition of `std::find` as a IWYU

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

lebedev.ri added a comment. In D105439#2874706 , @ldionne wrote: > I'm not entirely sure I understand the purpose of this patch. So the idea is > that let's say a tool suggests including `<__algorithm/find.h>` to get the > definition of `std::find` as a

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

ldionne added a comment. I'm not entirely sure I understand the purpose of this patch. So the idea is that let's say a tool suggests including `<__algorithm/find.h>` to get the definition of `std::find` as a IWYU fix-it sort of suggestion, the user would naively do that, and then the compiler (

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

cjdb added a comment. In D105439#2871429 , @Quuxplusone wrote: > Given that the goal is to get `include-what-you-use` to stop suggesting that > users `#include <__detail/fooimpl.h>` when what they want is spelled > ``, I think what's desired here (if a

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

Quuxplusone added a comment. Given that the goal is to get `include-what-you-use` to stop suggesting that users `#include <__detail/fooimpl.h>` when what they want is spelled ``, I think what's desired here (if anything) would be a pragma targeted at `include-what-you-use` (and other tools). Ba

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

cjdb added a comment. Ping @aaron.ballman and @ldionne 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 h

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

cjdb added a comment. I tried the following, but it doesn't work with modules, so it looks like a compiler solution is necessary. // in #define _LIBCPP_PRIVATE_HEADER_ALLOWED // in <__algorithm/find.h> #ifndef _LIBCPP_PRIVATE_HEADER_ALLOWED #error This is a libc++ detail header. Pl

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

cjdb added a comment. I should note that I didn't use private headers in libc++'s `modules.modulemap` because it created a very noticeable impact to our test suite's run-time. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D105439/new/ https://revie

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

cjdb added a comment. In 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 rang

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

Quuxplusone added a comment. I should add that if any particular library really wants to //enforce// "thou shalt not deep-link detail headers" (instead of just documenting it and/or relying on the user-programmer's common sense) they can do it pretty

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

lebedev.ri added a comment. 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? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

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

Quuxplusone requested changes to this revision. Quuxplusone added a comment. This revision now requires changes to proceed. 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 librar

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

cjdb added a comment. A few notes to reviewers: - The patch assumes everything is under a top-level `__libcxx` directory, because it seems there are other system headers that could be prefixed with `__`. libc++ currently has many top-level directories, following the trend of `__${STD_LIB_HEADE

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

cjdb created this revision. cjdb added reviewers: aaron.ballman, rsmith, manojgupta, gbiv, ldionne, EricWF. Herald added a reviewer: george.burgess.iv. cjdb requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. libc++ has started splicing standar