Skip to content
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

Fix false positives on closure rules on Swift 2.3 #1081

Merged
merged 4 commits into from
Dec 29, 2016
Merged

Fix false positives on closure rules on Swift 2.3 #1081

merged 4 commits into from
Dec 29, 2016

Conversation

marcelofabri
Copy link
Collaborator

@marcelofabri marcelofabri commented Dec 29, 2016

This should fix #1019

Maybe we should have a way of running the tests on all Swift versions 🤔

@SwiftLintBot
Copy link

SwiftLintBot commented Dec 29, 2016

1 Warning
⚠️ This PR may need tests.

Generated by 🚫 danger

@codecov-io
Copy link

codecov-io commented Dec 29, 2016

Current coverage is 83.23% (diff: 62.50%)

Merging #1081 into master will decrease coverage by 0.05%

@@             master      #1081   diff @@
==========================================
  Files           148        148          
  Lines          7215       7225    +10   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits           6010       6014     +4   
- Misses         1205       1211     +6   
  Partials          0          0          

Powered by Codecov. Last update e2657a9...77446ed

Copy link
Collaborator

@jpsim jpsim left a comment

Choose a reason for hiding this comment

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

To test with a different toolchain that we're using to compile, we just need to set the $XCODE_DEFAULT_TOOLCHAIN_OVERRIDE environment variable when invoking the tests via xcodebuild or swift test, as documented in How is SourceKit Resolved?.

This could be added as a separate script in Travis.

But not all tests could be run in Swift 2.x mode, since some of them lint Swift 3 code (like the integration tests) so we'd also need to whitelist which tests to run.

Obviously that shouldn't be done in this PR, if at all.

@@ -52,6 +52,11 @@
[Marcelo Fabri](https://github.com/marcelofabri)
[#928](https://github.com/realm/SwiftLint/issues/928)

* Fix false positives on `closure_parameter_position` and
`unused_closure_parameter` rules on Swift 2.3.
Copy link
Collaborator

Choose a reason for hiding this comment

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

"with Swift 2.x" instead of "on Swift 2.3"

@@ -27,7 +27,13 @@ extension Dictionary where Key: ExpressibleByStringLiteral {
}

if SwiftDeclarationKind(rawValue: kindString) == .varParameter {
return [subDict]
let nestedParameters = subDict.enclosedVarParameters
Copy link
Collaborator

Choose a reason for hiding this comment

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

Shouldn't this switch on the current Swift version instead?

case three

static let current: SwiftVersion = {
let file = File(contents: "#sourceLocation()")
Copy link
Collaborator

Choose a reason for hiding this comment

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

We should propose that a request type be added to SourceKit to get the current Swift version. But this is good for now.

@@ -27,7 +27,13 @@ extension Dictionary where Key: ExpressibleByStringLiteral {
}

if SwiftDeclarationKind(rawValue: kindString) == .varParameter {
return [subDict]
let nestedParameters = subDict.enclosedVarParameters
// on Swift 2.3, a closure parameter is inside another .varParameter and not inside an .argument
Copy link
Collaborator

Choose a reason for hiding this comment

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

Generally "with Swift X.Y", not "on Swift X.Y".

@marcelofabri
Copy link
Collaborator Author

@jpsim We can also create another scheme in Xcode changing the value of TOOLCHAINS env var (it's already being set to ${TOOLCHAINS}). In that scheme we can disable the Swift 3 tests.

Besides the integration tests (that I've disabled), the only two currently failing tests are:

  • attributes rule: there's some history on the PR that added this rule, but basically some attributes were just added on Swift 3
  • number_separator rule: it seems that with Swift 3, SourceKit reports the negative sign as part of the number but Swift 2.3 doesn't, so it's only a matter of where the violation marker should be.

@@ -23,4 +23,11 @@ enum SwiftVersion {

fatalError("Unexpected Swift version")
}()

var nameKey: String {
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is now used in just one place, keep it there? This shouldn't be a widely used thing.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

👍

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Actually this is being used on enclosedVarParameters as well 🤔

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

But I could use "key.typename" directly there, as it's used inside the switch. What do you think would be better?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I think nameKey isn't representative of the conditional value it returns. Copying the code inline avoids coming up with an accurate name for it. So either come up with a good name, or skirt around the issue :-)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I've created a private nameKey(for version: SwiftVersion) function where it's really needed. I hope it's a good enough name as it's private 😅

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yup!

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.

False positive on closure_parameter_position with Swift 2.3
4 participants