[5.9 🍒][Dependency Scanner] Ensure the Clang dependency scanner working directory matches the invocation when querying bridging header dependencies #65438
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ctory matches the invocation when querying bridging header dependencies The Swift compiler does not have a concept of a working directory. It is instead handled by the Swift driver by resolving relative paths according to the driver's working directory argument. On the other hand, Clang does have a concept working directory which may be specified on this Clang invocation with '-working-directory'. If so, it is crucial that we use this directory as an argument to the Clang scanner API. Otherwiswe, we risk having a mismatch between the working directory specified on the scanner's Clang invocation and the one use from the scanner API entry-points, which leads to downstream inconsistencies and errors. This was originally fixed for the main by-name module dependencies query in swiftlang#61025 (03136e0), but the Bridging Header dependencies code has continued to incorrectly expect the Swift ASTContext to both have the working directory set *and* be consistent with that of the Clang scanner instance. Resolves rdar://108464467
nkcsgexi
approved these changes
Apr 26, 2023
|
@swift-ci test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-pick of #65436
• Release: Swift 5.9
• Explanation: The Swift compiler does not have a concept of a working directory. It is instead handled by the Swift driver by resolving relative paths according to the driver's working directory argument. On the other hand, Clang does have a concept working directory which may be specified on this Clang invocation with '-working-directory'. If so, it is crucial that we use this directory as an argument to the Clang scanner API. Otherwiswe, we risk having a mismatch between the working directory specified on the scanner's Clang invocation and the one use from the scanner API entry-points, which leads to downstream inconsistencies and errors.
• Scope of Issue: Scanner may crash or produce incorrect results when queried by the Swift scanner which decides on a working directory that may differ from that the built-in Clang is instantiated with.
• Origination: The scanner has been designed in this way from the beginning, this relevant check was simply missing. It was previously fixed for the main code-path of querying Clang dependencies, but not for the code-path of Bridging Header dependencies.
• Risk: Zero risk to implicit module builds, minimal risk to explicit module builds.
Resolves rdar://108464467