-
Notifications
You must be signed in to change notification settings - Fork 204
[Incremental] Harness immutability to make inputDependencySourceMap
robust
#675
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
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This tells me that we are no longer reading in swiftdeps files from serialized priors. I'm lacking context here to understand the implications of this, where were these deserialized files used?
They are one of the examples that made the
SourceMap
not-truly-bijective, is it the case that they never led to correct behavior? Or if they resulted in another behavior, where were we relying on it that we now choose not to?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I understand the confusion here.
The intention of this change is to no longer serialize and deserialize the
inputDependencySourceMap
. SerializedmapNode
s were only used for that purpose. We still read inModuleDependencyGraph
s from the priors.Yes, serializing the map and then deserialized it created confusion because the deserialized version might be inconsistent with the info from the
OutputFileMap
. This PR is premised on the believe that it is theOutputFileMap
that should be the source of truth.Does this explanation satisfy? Have I missed something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes that makes sense, thank you. And it also makes sense for the output-file-map to be the canonical source of truth. Probably so much so that I am wondering why we serialized the
inputDependencySourceMap
in the first place, hence the confusion.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for validating the notion of output-file-map as canonical. Wrt to serializing the
inputDependencySourceMap
I have to plead mea culpa. It seemed like a good idea at the time because theinputDependencySourceMap
was being dynamically build asswiftdeps
files were processed. When @CodaFi added the prior deserialization code, IIRC, there was a moment when we had deserialized priors with an empty map. So I (wrongly) fixed it by serializing theinputDependencySourceMap
. My mistake, in conjuction with the build system's proclivity to change file names when a C++ file and Swift file had the same basename-without-extension, led to hilarity ensuing. @CodaFi got to the bottom of things there, and identified the problems with that design.Later, I realized that the output-file-map should just be the truth, and that, consequently, the
inputDependencySourceMap
could be both immutable and a bijection. I hope I'm right this time!