Skip to content

Cleanup SPMTestSupport Module #3019

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 22 commits into from
Nov 7, 2020

Conversation

mattt
Copy link
Contributor

@mattt mattt commented Nov 4, 2020

One last incremental PR in service of #2967, this time doing some clean up in the SPMTestSupport module.

In my work to update the semantics of Swift package identity, I've spent a lot of time in Workspace-adjacent tests. And one of the things that's been tripping me up is the use of Test___ as a prefix for supporting types, like TestTarget and TestProduct, which I often conflate with .testTarget or the like. I think the prefix Mock___ provides clearer, more descriptive names for these types.

Along the way, I also fixed some unused or misnamed APIs that I encountered. For example, there was an unused MockDependencyGraph type in addition to a MockGraph type that was used, so I renamed the latter to the former (2f283f0).

As always, most of these changes are severable from one another and can be picked or dropped a la carte.

Edit: Any incidental formatting or whitespace changes are from SwiftFormat (#3012), which I have set up to run automatically in a pre-commit hook (.git/hooks/pre-commit) for each staged file:

#!/bin/bash
git-format-staged --formatter "swiftformat stdin --stdinpath '{}'" "*.swift"

@mattt

This comment has been minimized.

@mattt
Copy link
Contributor Author

mattt commented Nov 4, 2020

@swift-ci please smoke test

@@ -61,48 +59,48 @@ public final class TestWorkspace {
self.skipUpdate = skipUpdate
self.enablePubGrub = enablePubGrub

try create()
try self.create()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are all these self. additions just stylistic? I think the general Swift approach (and the one used in SwiftPM) is to not specify self. when it's not needed (such as in an escaping closure).

Copy link
Contributor Author

@mattt mattt Nov 5, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These were automatically inserted by SwiftFormat, for which @tomerd added the configuration with #3012. I believe we share stylistic preferences, but I'm more than happy to accede to any conventions enforced by a formatter.

That said, I've encountered a few situations in which SwiftFormat makes source-breaking changes to Swift Package Manager. Namely, mistakenly inserting self. for things like break labels and local variables whose names shadow an instance method or property. To reproduce this, try running swiftformat with the current settings on Sources/Workspace/Workspace.swift.

I'm working to share minimal examples with the maintainer, but this may be cause for reconsidering how automatic formatting is currently set up.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are all these self. additions just stylistic? I think the general Swift approach (and the one used in SwiftPM) is to not specify self. when it's not needed (such as in an escaping closure).

These were automatically inserted by SwiftFormat, for which @tomerd added the configuration with #3012. I believe we share stylistic preferences, but I'm more than happy to accede to any conventions enforced by a formatter.

In other projects (SwiftNIO, etc) we actually encouraged adding self. to make sure things are very explicit. happy to open up for discussion tho. cc @weissi

That said, I've encountered a few situations in which SwiftFormat makes source-breaking changes to Swift Package Manager. Namely, mistakenly inserting self. for things like break labels and local variables whose names shadow an instance method or property.

interesting. I have not had such trouble with SwiftFormat in other projects, what version are you using @mattt?

Copy link
Contributor

@tomerd tomerd Nov 5, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mattt in any case dont let this block progress. you can run the formatter without the self setting if it breaks things and we can revisit this separately

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tomerd According to swiftformat --version, I'm using the latest (0.47.2). For now, I'm committing with --no-verify to skip my pre-commit hook as necessary. So this isn't a blocker.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine, it's just opposite of what I've seen before so I wanted to ask.

public func XCTAssertEqual<T: CustomStringConvertible>(
_ assignment: [(container: T, version: Version)],
_ expected: [T: Version],
file: StaticString = #file, line: UInt = #line
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this code is already being moved around now, should this be switched to #fileId to avoid future warnings about #fileId vs #filePath (once they come back)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the interest of keeping this focused, let's punt on that. For something like #file usage, I think we'll want to change everything project-wide at once, rather than adopting piecemeal over time.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good.

@@ -138,7 +138,7 @@ class PIFBuilderTests: XCTestCase {
v: .v5_2,
packageKind: .remote,
products: [
.init(name: "BarLib", targets: ["BarLib"]),
.init(name: "BarLib", type: .library(.automatic), targets: ["BarLib"]),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this a needed change? The default type should be automatic. Or is the intent that for the PIF, the type is always spelled out?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a consequence of a3a67f9, which removes a helper overload that implies the type parameter. I found the ambiguity at the call site not to be worth the benefit of the affordance. If it makes sense for this to be the default argument, I think that change should be made in the original declaration.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for clarifying.

@abertelrud
Copy link
Contributor

Thanks for all the continuing cleanup, @mattt! I agree about the change from Test to Mock, but just had a couple of questions about the other changes.

@mattt
Copy link
Contributor Author

mattt commented Nov 5, 2020

@abertelrud Thanks so much for reviewing this. I just finished responding to all of your feedback. Let me know if there's anything else you'd like to discuss before merging this in.

@abertelrud
Copy link
Contributor

Thanks, this looks great. FYI, I also have a separate change to make SPMTestSupport able to be used for libSwiftPMDataModel, but we can merge yours first and I can rebase on that.

@abertelrud abertelrud self-requested a review November 7, 2020 00:07
Copy link
Contributor

@abertelrud abertelrud left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this ready to merge?

@abertelrud
Copy link
Contributor

Actually, based on your previous comment it sounds as if it is, so I'll merge.

@abertelrud abertelrud merged commit b565edc into swiftlang:main Nov 7, 2020
@mattt mattt deleted the spmtestsupport-module-cleanup branch November 7, 2020 12:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants