DmitryPolukhin added a comment. In D157283#4648242 <https://reviews.llvm.org/D157283#4648242>, @ldionne wrote:
> As explained in https://reviews.llvm.org/D89001#4648241, upstream Clang is > the way it should be right now. The intent is that we first look along the > `clang` binary for headers (that way if you install a custom libc++ it will > be picked up), and then we fall back to the SDK version. It's just > unfortunate that AppleClang has lagged behind a bit and created some > confusion, but I believe the latest release should have the exact same > behavior as upstream Clang wrt search paths. The commit mentioned above > (`9edb9a711503d540cf3126c0fde11ce9a0d9a7aa`) as actually just making > downstream back in sync with upstream. So IMO the correct thing to do is to > abandon this change and wait for a new AppleClang that has matching behavior > with upstream Clang (it's probably in Xcode 15 RC which came out recently). @ldionne thank you for the reply. Unfortunately current behaviour makes problems for clang-tools like clang-tidy and clangd that read CDBs from `compile_commands.json`. They start looking headers relative to compiler path specified in CDB but it is better to use path specified in -isysroot (it is what user expects when they specify the option). What is the rationale behind ignoring `-isysroot` specified in command line? If user would like to use search path relative to compiler, they could just remove `-isysroot` and get this behaviour. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D157283/new/ https://reviews.llvm.org/D157283 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
