arphaman added a comment. Apologies for not seeing this earlier. I agree with George, this behavior doesn't seem right to me.
> 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. 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. 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. 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
