Skip to content

[ClangImporter] Include -Xcc options in the PCH hash #27482

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 2, 2019

Conversation

jrose-apple
Copy link
Contributor

While most -Xcc options turn into options that affect the Clang module cache hash, some, like search paths, do not, and that can have a drastic effect on PCH contents. When combined with places where Xcode will modify invocations to add extra -Xcc options (see rdar://problem/23297285), this can lead to crashes where the modified-invocation PCH is used to compile source files in incremental mode, and then the original, non-precompiled bridging header is used for module merging. Let's just be conservative and include -Xcc options in the Swift-side PCH uniqueness hash.

rdar://problem/33837253

While most -Xcc options turn into options that affect the Clang module
cache hash, some, like search paths, do not, and that can have a
drastic effect on PCH contents. When combined with places where Xcode
will modify invocations to add extra -Xcc options (see
rdar://problem/23297285), this can lead to crashes where the
modified-invocation PCH is used to compile source files in incremental
mode, and then the original, non-precompiled bridging header is used
for module merging. Let's just be conservative and include -Xcc
options in the Swift-side PCH uniqueness hash.

rdar://problem/33837253
@jrose-apple
Copy link
Contributor Author

@swift-ci Please test

@jrose-apple
Copy link
Contributor Author

@swift-ci Please test source compatibility

// RUN: %target-swift-frontend -emit-pch -pch-output-dir %t/pch-Xcc %S/Inputs/sdk-bridging-header.h
// RUN: %target-swift-frontend -emit-pch -pch-output-dir %t/pch-Xcc %S/Inputs/sdk-bridging-header.h -Xcc -Ifoo
// RUN: %target-swift-frontend -emit-pch -pch-output-dir %t/pch-Xcc %S/Inputs/sdk-bridging-header.h -Xcc -Ibar
// RUN: ls %t/pch-Xcc/*swift*clang*.pch | count 3
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think count just prints the number of elements, it doesn't validate how many elements were passed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does, actually! I made sure to test this with the 5.1 compiler.

(I think it's an LLVM tool, not a shell builtin.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jrose-apple
Copy link
Contributor Author

Looks like the Release build source compat suite failure is also happening on master.

@jrose-apple jrose-apple merged commit 5883345 into swiftlang:master Oct 2, 2019
@jrose-apple jrose-apple deleted the search-party branch October 2, 2019 18:28
jrose-apple added a commit to jrose-apple/swift that referenced this pull request Oct 2, 2019
While most -Xcc options turn into options that affect the Clang module
cache hash, some, like search paths, do not, and that can have a
drastic effect on PCH contents. When combined with places where Xcode
will modify invocations to add extra -Xcc options (see
rdar://problem/23297285), this can lead to crashes where the
modified-invocation PCH is used to compile source files in incremental
mode, and then the original, non-precompiled bridging header is used
for module merging. Let's just be conservative and include -Xcc
options in the Swift-side PCH uniqueness hash.

rdar://problem/33837253
(cherry picked from commit 5883345)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants