ilya-biryukov added a comment. In https://reviews.llvm.org/D54310#1296080, @arphaman wrote:
> Apologies for not seeing this earlier. No worries, thanks for the input! >> The logic to do this was based on resource dir as an approximation of >> where the compiler is installed. This broke the tools that read >> 'compile_commands.json' and don't ship with the compiler, as they >> typically change resource dir. > > In that case I think the tool should adjust the `-resource-dir` to point to > the appropriate `-resource-dir` for the compiler in the toolchain. However, > that comes with its own problems, as the builtin headers might be > incompatible between the tool and the compiler in the toolchain. Exactly the problem we're facing. Since the -resource-dir is primarily used to find the builtin headers, we **have** to override it in the tools to avoid breaking them. > In that case I think it would be preferable for the tool to ship with its own > libc++ headers in addition to the builtin headers rather than implementing > this behavior. There's value in providing the users with warnings/errors from exactly the same version of the C++ standard library that's used by the compiler, so I would avoid going down this path if possible. > If that's unacceptable I think we should adjust libTooling to add a search > path for the libc++ headers when the tool detects that it's running outside > of the toolchain on Darwin (i.e. 'clang' doesn't exist in the same directory > as the tool, and '../include/c++' doesn't exist as well) instead of changing > this behavior. This was the original intention of the patch, but I don't think we should limit this to libTooling. I'll have a look at what exactly lldb broke and will come up with a fix to this behavior. Repository: rL LLVM https://reviews.llvm.org/D54310 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
