[ClangImporter] clang's -iframework comes before builtin usr/local/include, but Swift's -Fsystem comes after #78303
Conversation
ian-twilightcoder
requested review from
ahoppen,
bnbarham,
hamishknight,
rintaro,
artemcm,
xymus,
hborla,
slavapestov,
xedin,
tshortli,
QuietMisdreavus,
eeckstein,
jckarter,
zoecarver,
hyp,
egorzhdan,
beccadax and
Xazax-hun
as code owners
ian-twilightcoder
force-pushed
the
clang-importer-search-paths
branch
2 times, most recently
from
5b5c247 to
86aba97
Compare
ian-twilightcoder
force-pushed
the
clang-importer-search-paths
branch
from
86aba97 to
613292a
Compare
😁 Is it a problem that this requires a lock-step lldb change? I can't come up with anything clever to avoid that since I can't overload |
Seems that an LLDB lockstep change is a lesser evil here, to me. |
ian-twilightcoder
force-pushed
the
clang-importer-search-paths
branch
from
613292a to
60db7a0
Compare
ian-twilightcoder
force-pushed
the
clang-importer-search-paths
branch
from
60db7a0 to
336cb84
Compare
ian-twilightcoder
changed the title
|
…clude, but Swift's -Fsystem comes after When Swift passes search paths to clang, it does so directly into the HeaderSearch. That means that those paths get ordered inconsistently compared to the equivalent clang flag, and causes inconsistencies when building clang modules with clang and with Swift. Instead of touching the HeaderSearch directly, pass Swift search paths as driver flags, just do them after the -Xcc ones. Swift doesn't have a way to pass a search path to clang as -isystem, only as -I which usually isn't the right flag. Add an -Isystem Swift flag so that those paths can be passed to clang as -isystem. rdar://93951328
ian-twilightcoder
force-pushed
the
clang-importer-search-paths
branch
from
336cb84 to
cdb42c3
Compare
|
@swift-ci smoke test |
| // RUN: %target-swift-frontend -sdk %t/sdk -typecheck -I %t/sdk/custom/include -module-cache-path %t/mcp5 %t/SearchPathOrder.swift | ||
| // RUN: %target-swift-frontend -sdk %t/sdk -typecheck -Isystem %t/sdk/custom/include -module-cache-path %t/mcp6 %t/SearchPathOrder.swift | ||
| // RUN: %target-swift-frontend -sdk %t/sdk -typecheck -F %t/sdk/custom/Frameworks -module-cache-path %t/mcp7 %t/SearchPathOrder.swift | ||
| // RUN: %target-swift-frontend -sdk %t/sdk -typecheck -Fsystem %t/sdk/custom/Frameworks -module-cache-path %t/mcp8 %t/SearchPathOrder.swift |
There was a problem hiding this comment.
I don't know why, but this passes in main but fails in the current Xcode version. I'll have to double check this test when this builds into an Xcode to make sure this change fixes it.
When Swift passes search paths to clang, it does so directly into the HeaderSearch. That means that those paths get ordered inconsistently compared to the equivalent clang flag, and causes inconsistencies when building clang modules with clang and with Swift. Instead of touching the HeaderSearch directly, pass Swift search paths as driver flags, just do them after the -Xcc ones.
Swift doesn't have a way to pass a search path to clang as -isystem, only as -I which usually isn't the right flag. Add an -Isystem Swift flag so that those paths can be passed to clang as -isystem.
rdar://93951328