lebedev.ri added a comment. In D105439#2874706 <https://reviews.llvm.org/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 fix-it sort of suggestion, the user would > naively do that, and then the compiler (with this patch) would error out > saying "woops, you can't include that libc++ detail header". Is that the idea? > > If that's it, then I would much rather fix the tools that incorrectly suggest > including those implementation detail headers in the first place. Users will > be less confused and we won't have to special-case a special directory name, > which I can imagine could cause issues. I think it's great to try and give > the proper diagnostic to users, but I think the correct place to do that is > in the tool that suggests it in the first place. Thoughts? Regardless of whether this is about enhacing IWYU QoL or completely preventing inclusion of separate sub-headers, it seems like that should be done in libc++ itself, it already has the means for that. 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
