[PATCH] D54310: Make clang-based tools find libc++ on MacOS

[Ilya Biryukov via Phabricator via cfe-commits]

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