[6.2 🍒][Dependency Scanning] Fix search path context hashing hole and avoid serializing unnecessary field #81255
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 #81244
Only the top two commits are new, the oldest commit in this PR is under standalone review in #81254
Explanation: This change addresses an issue in incremental dependency scanning where the scanner would incorrectly re-use prior scanning results if the prior scan was different from the current scan by having identical search paths specified as Non-System and the current scan has the same search paths specified as System, and vice versa. This is due to the PCH search path hash code, which is also used for the dependency scanning hash. In both cases, PCH contents may differ based on whether a certain module they depend on is found in a system or non-system search path. This change also removes a field
auxiliaryFiles
from getting serialized. This field, in caching builds, is not required to be serialized.Problem: rdar://150307865 & rdar://150334077
Risk: Low, the change to the hashing function used in this PR is to make it more strict, in a way it should always have been, which should make it more sound. The change to remove serialization of
auxiliaryFiles
is expected to be a no-op.Testing: Added tests to test suite
Original PRs: #81244
Reviewers: @cachemeifyoucan