Skip to content

Conversation

@compnerd
Copy link
Contributor

This pull request adds support for testing SwiftLint rule examples on Windows, alongside existing support for Linux and macOS. The most significant changes include introducing a new testOnWindows property to the Example model, updating rule example definitions to use this property, and modifying test helpers to conditionally run tests based on platform. Additionally, Windows-specific logic for test setup has been added to ensure compatibility.

Platform support enhancements:

  • Added a new testOnWindows property to the Example struct and updated its initializer to allow specifying whether an example should be tested on Windows. (Source/SwiftLintCore/Models/Example.swift) [1] [2]
  • Updated all relevant rule example definitions to include the testOnWindows: false flag where appropriate, ensuring tests are only run on supported platforms. (Source/SwiftLintBuiltInRules/Rules/Lint/UnusedImportRuleExamples.swift) [1] [2] [3]

Test infrastructure improvements:

  • Modified test helpers to check the new testOnWindows property before running tests, analogous to the existing Linux checks. (Tests/TestHelpers/TestHelpers.swift)
  • Added Windows-specific logic for platform information decoding and test setup, including adjustments to compiler flags and additional import paths for XCTest. (Tests/TestHelpers/TestHelpers.swift) [1] [2]

Mirror the `testOnLinux` for Windows with a `testOnWindows`. This allows
us to skip some tests dynamically as we do on Linux.
@SwiftLintBot
Copy link

SwiftLintBot commented Nov 21, 2025

1 Warning
⚠️ If this is a user-facing change, please include a CHANGELOG entry to credit yourself!
You can find it at CHANGELOG.md.
18 Messages
📖 Building this branch resulted in the same binary size as when built on main.
📖 Linting Aerial with this PR took 0.76 s vs 0.75 s on main (1% slower).
📖 Linting Alamofire with this PR took 1.05 s vs 0.99 s on main (6% slower).
📖 Linting Brave with this PR took 6.79 s vs 6.79 s on main (0% slower).
📖 Linting DuckDuckGo with this PR took 21.86 s vs 21.83 s on main (0% slower).
📖 Linting Firefox with this PR took 10.82 s vs 10.84 s on main (0% faster).
📖 Linting Kickstarter with this PR took 7.49 s vs 7.49 s on main (0% slower).
📖 Linting Moya with this PR took 0.42 s vs 0.45 s on main (6% faster).
📖 Linting NetNewsWire with this PR took 2.24 s vs 2.25 s on main (0% faster).
📖 Linting Nimble with this PR took 0.65 s vs 0.61 s on main (6% slower).
📖 Linting PocketCasts with this PR took 7.03 s vs 7.04 s on main (0% faster).
📖 Linting Quick with this PR took 0.4 s vs 0.38 s on main (5% slower).
📖 Linting Realm with this PR took 3.21 s vs 3.18 s on main (0% slower).
📖 Linting Sourcery with this PR took 1.79 s vs 1.78 s on main (0% slower).
📖 Linting Swift with this PR took 4.16 s vs 4.18 s on main (0% faster).
📖 Linting VLC with this PR took 1.05 s vs 1.07 s on main (1% faster).
📖 Linting Wire with this PR took 17.3 s vs 17.32 s on main (0% faster).
📖 Linting WordPress with this PR took 11.28 s vs 11.26 s on main (0% slower).

Here's an example of your CHANGELOG entry:

* Tests: repair the Generation tests on Windows.  
  [compnerd](https://github.com/compnerd)
  [#issue_number](https://github.com/realm/SwiftLint/issues/issue_number)

note: There are two invisible spaces after the entry's text.

Generated by 🚫 Danger

Windows isolates XCTest/Testing from the platform SDK as they are not
part of the redistributable components. We adjust the flags by querying
the partial path information and computing the location for the `XCTest`
module for the tests.

Additionally, enable the ObjC interop on the test cases to allow parsing
`@objc` modifiers on declarations. This allows us to pass the
GeneratedTests test suite.
@roman-bcny
Copy link
Contributor

Neat!

Copy link
Collaborator

@SimplyDanny SimplyDanny left a comment

Choose a reason for hiding this comment

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

Looks good to me apart from two nits.

We could probably come up with semantically equal test cases that would also work on Windows, but excluding them is also fine as we're not testing anything platform-related. So logic that works on Linux/macOS will also work on Windows anyway.

.deletingLastPathComponent()
.deletingLastPathComponent()
.appendingPathComponent("Library")
.appendingPathComponent("XCTest-\(info.defaults.versionXCTest)")
Copy link
Collaborator

Choose a reason for hiding this comment

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

We could use

Suggested change
.appendingPathComponent("XCTest-\(info.defaults.versionXCTest)")
.appendingPathComponent("XCTest-\(SwiftVersion.current.rawValue)")

here which directly interacts with SourceKit to retrieve the version. Not sure whether it's safe to assume that Swift version == XCTest version, though. For the 6.2.1 toolchain, that's the case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think that is entirely safe to assume (though it does currently hold). That is the reason for the deserialisation of the plist - it encodes the information for the SDK itself which is embedded at build time.

@SimplyDanny
Copy link
Collaborator

Relates to #6352.

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