Revert logic in cacheKey
calculation introduced in #1163
#1200
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.
Context
The way cacheKey was calculated before #1163 was that includedFiles collection was empty, whereas after #1163, that collection always contains file paths.
Because of the aforementioned change in the logic of calculating
cacheKey
hash, the following issue occurs:buildDir
path includes all files in.build
folder, and thus,cacheKey
depends on thebuild
folder contentsbuildDir
contains files likemaster.swiftdeps
,.swiftsourceinfo
,main.swift.o
,DWARF/SwiftTemplate
,build.db
,context.bin
, which change every time a build is performed (I suppose timestamp is used in these files in one way or another).Solution
Revert this change and advise to use
--cacheDisabled
flag because it would provide exactly the same behaviour as it is now in version 2.0.3.Resolves #1196