This is an archive of the discontinued LLVM Phabricator instance.

[clang] Match -isysroot behaviour with system compiler on Darwin
AcceptedPublic

Authored by DmitryPolukhin on Aug 7 2023, 7:11 AM.

Details

Summary

See discussion in https://reviews.llvm.org/D89001

I updated test to match actual behavior of
/Applications/Xcode_14.3.1_14E300b.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
after that modified upstream to match the test.

Diff Detail

Event Timeline

DmitryPolukhin created this revision.Aug 7 2023, 7:11 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 7 2023, 7:11 AM
DmitryPolukhin requested review of this revision.Aug 7 2023, 7:11 AM
dexonsmith resigned from this revision.Aug 7 2023, 7:34 AM
dexonsmith added subscribers: arphaman, jroelofs.

This looks correct to me, but I'd rather have someone at Apple confirm. @ldionne (or @arphaman or @jroelofs), can you review and/or help to find the right person?

Update comments

rmaz added a subscriber: rmaz.Aug 7 2023, 10:21 AM

@ldionne, @arphaman and @jroelofs, friendly ping, could you please take a look?

jroelofs accepted this revision.Aug 23 2023, 9:05 AM

LGTM, thank you!

This revision is now accepted and ready to land.Aug 23 2023, 9:05 AM

I don't know how, but somehow this change breaks clang-tidy/infrastructure/clang-tidy-mac-libcxx.cpp test.

jroelofs added a comment.EditedAug 23 2023, 1:30 PM

I don't know how, but somehow this change breaks clang-tidy/infrastructure/clang-tidy-mac-libcxx.cpp test.

I think we have a patch for that... @ldionne WDYT about upstreaming 9edb9a711503d540cf3126c0fde11ce9a0d9a7aa ?

I will revert this for now, as this change broke Darwin CI:

https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/37169/

Clang.Tooling.clang-check-mac-libcxx-abspath.cpp
Clang.Tooling.clang-check-mac-libcxx-relpath.cpp

@ldionne has a patch for these tests I believe, please coordinate with him before recommitting this change

@ldionne could you please upstream 9edb9a711503d540cf3126c0fde11ce9a0d9a7aa (I don't know what it is)?
Alternatively I can figure out what to do with this test (it is just copies of the same test with minimal modifications) with a hint how it was resolved to make sure that it worn diverse from want it should be on Darwin.

DmitryPolukhin reopened this revision.Aug 29 2023, 6:20 AM
This revision is now accepted and ready to land.Aug 29 2023, 6:20 AM

@ldionne could you please upstream 9edb9a711503d540cf3126c0fde11ce9a0d9a7aa (I don't know what it is)?
Alternatively I can figure out what to do with this test (it is just copies of the same test with minimal modifications) with a hint how it was resolved to make sure that it worn diverse from want it should be on Darwin.

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).

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.