[ClangImporter] Don't add duplicate search paths #12169
Conversation
|
@swift-ci Please test |
|
Build failed |
Besides saving some calls to stat(), this also causes problems when the user specifies a search path that Clang already adds by default, like $SDKROOT/Library/Frameworks/. Why? Because Swift adds its search paths after Clang has already configured its defaults, but Clang reconfigures its search paths from scratch when compiling a module to a PCM file to cache. This led to system search paths being found sooner in the primary Clang instance than in the PCM files, which in turn resulted in the PCM files being considered out of date. This isn't likely to affect people much in practice, but it's better to get right. (We ran into this during Doug's experiments in making /System/Library/PrivateFrameworks a default search path in Clang r313317; turns out that's problematic for other reasons as well.) rdar://problem/34664596
We don't want to show "included from <bridging-header>" to the user-- that's just not helpful--but we /do/ want to see any unexpected diagnostics that happen to be reported in the importer's synthetic buffers. This would have helped us track down rdar://problem/34664596 much sooner.
jrose-apple
force-pushed
the
dance-dance-deduplication
branch
from
308f2c6 to
d78d1dc
Compare
|
@swift-ci Please test |
|
Build failed |
|
Build failed |
|
@swift-ci Please test source compatibility |
|
This is not at all urgent but I'd like to merge it before it gets stale. Review ping? @swift-ci Please smoke test |
|
Jenkins issue @swift-ci Please smoke test Linux |
@aciidb0mb3r, interesting or no? @swift-ci Please smoke test Linux |
|
@jrose-apple Looks random, have you seen this before? |
|
Nope, but anything that does network access seems suspicious to be in the test suite. |
|
It is mocked, nothing in the SwiftPM test suite requires network access :) |
|
@swift-ci Please smoke test Linux |
|
Thanks, Doug. Let's double-check that nothing changed… @swift-ci Please smoke test |
|
@swift-ci Please smoke test Linux |
Besides saving some calls to
stat(), this also causes problems when the user specifies a search path that Clang already adds by default, like $SDKROOT/Library/Frameworks/. Why? Because Swift adds its search paths after Clang has already configured its defaults, but Clang reconfigures its search paths from scratch when compiling a module to a PCM file to cache. This led to system search paths being found sooner in the primary Clang instance than in the PCM files, which in turn resulted in the PCM files being considered out of date.This isn't likely to affect people much in practice, but it's better to get right. (We ran into this during Doug's experiments in making /System/Library/PrivateFrameworks a default search path in Clang r313317; turns out that's problematic for other reasons as well.)
While here, tweak the filtering for Clang diagnostics so that next time something like this breaks we'll actually see it in the build log.
rdar://problem/34664596