-
Notifications
You must be signed in to change notification settings - Fork 1.4k
refactor serialization and state management #3696
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
Conversation
47fe878
to
f284806
Compare
@swift-ci please smoke test |
3ea2e7d
to
3f0a2b0
Compare
@swift-ci please smoke test |
APIDiffTests seem to be failing on Linux on this PR and others - maybe the underlying API diff tool on Linux is broken / changed? does it even make sense for SwiftPM tests to test the APIDiff functionality given its only an integration shim (which we need to move to plugin!). @neonichu @abertelrud @elsh? |
motivation: stronger seperation between state managment format and data model, allowing evolution of storeage format changes: * refactor PinsStore, RepositoryManager, and WorkspaceState to model their state storage seperately from the data model * use Codable instead of JSONMappable/JSONSerializable/SimplePersistence * adjust call-sites and tests where necessary
3f0a2b0
to
c0b9d80
Compare
@swift-ci please smoke test |
@swift-ci please smoke test |
private let encoder = JSONEncoder.makeWithDefaults() | ||
private let decoder = JSONDecoder.makeWithDefaults() |
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.
Is there any particular advantage to keeping these around? (e.g. performance) Is there any concern about unintentional leaking of state from one encode/decode to the next?
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.
memory and performance. I dont think they hold any state.
// FIXME: We should emit a warning here using the diagnostic engine. | ||
TSCBasic.stderrStream.write("\(error)\n") | ||
TSCBasic.stderrStream.write("warning: unable to restore workspace state: \(error)") |
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 realize this is existing code, so doesn't need to be changed in this PR, but should a future PR change this to use a Diagnostics
collector since I assume this could be emitted from an IDE as well (as it's part of libSwiftPM)?
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.
the issue is that Workspace does not have a DiagnosticsEngine to use in this case. I was planning to address this in one of the next refactoring PRs, focused on making Diagnostics more globally available
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.
Yah, we have at least one more such case that we can clean up once we make diagnostics more broadly available.
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 is great cleanup!
fileprivate struct DestinationInfo: Codable { | ||
let target: String? | ||
let sdk: AbsolutePath? | ||
let binDir: AbsolutePath |
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 just noticed that this small change from this much larger pull changes the format for destination JSON files, rather than what's documented here and here.
@tomerd, should I update the docs and example for the new format or should we stick with the old format? I'll submit a pull for either way you want to go.
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.
@buttaface great catch, would appreciate such help
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.
actually, I think we can also consider the reverse it the old name is more correct - ie we could also rename / change the decoding to accept the old name, as the rename was more cleanup code wise
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.
iow the goal here was not to change the format / names, but an internal cleanup of the decoding to use Codable, the name change was an oversight, so happy to change back to the name if preferable
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.
def this is missing a test tho :D
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.
OK, I will change it back and add a test.
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.
Submitted two fixes in #3793, will submit the test later.
Motivation: The larger refactoring changed the destination JSON format and introduced a bug in passing flags. Changes: Use a CodingKeys enum to go back to the old format and correct the flag error.
motivation: stronger seperation between state managment format and data model, allowing evolution of storeage format
changes: