Windows Port #5030
Windows Port #5030
Conversation
Here's an example of your CHANGELOG entry: * Windows Port.
[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 |
SimplyDanny
left a comment
SimplyDanny
left a comment
There was a problem hiding this comment.
This basically looks fine to me. What about the open issues/PRs from other repositories you mentioned in the PR description? Is there anything more required to make SwiftLint work on Windows?
|
The only thing needed is to get the SourceKitten changes in (but haven't been able to get response from @jpsim to get those resolved and merged). |
Last I checked the windows PRs for some SwiftLint dependencies failed to build or failed tests for macOS or Linux. I’m happy to review again when those failures are addressed. |
| var ffd: WIN32_FIND_DATAW = WIN32_FIND_DATAW() | ||
|
|
||
| let hDirectory: HANDLE = String(cString: $0!).withCString(encodedAs: UTF16.self) { | ||
| FindFirstFileW($0, &ffd) |
There was a problem hiding this comment.
This doesn't appear to work for globs that include directories
SwiftLintPackageTests.xctest 21520 CreateFile C:\workspace\SwiftLint\Tests\FileSystemAccessTests\Resources\ProjectMock\Level1\*\*.swift NAME INVALID Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a
testExcludeByPrefixGlobExcludePaths runs this for Level1/*/*.swift, and on Windows only Level1/*.swift would work but Level1/*/*.swift gets treated as Level1/* dir with the *.swift glob, which can't find the dir and fails.
From a cursory research it seems Windows doesn't expose this as an api and we'll have to manually split the string and query recursively to handle such cases.
There was a problem hiding this comment.
I might be tougher than it seems as this is an area that has caused a lot of headaches in the past (even in the Unix case). See #6342 as an example where I try to improve performance (again). It also lists (some) issues related to that topic.
On the other hand, getting it to work at all on Windows should be doable. Performance is another topic then ...
Add some Windows specific handling for the paths in SwiftLintCore. The one piece that this change does not cover is the handling of `glob` as that is not an ISO C standard function and as such there is no `glob` on Windows. This will be worked through separately.
This enables building the swiftlint command on Windows. There is no system ioctl for terminal access, instead, we can use the Win32 Console API surface to query the console size. In the case of a failure, assume the width to be 80-columns (as the standard VGA console is 80x25).
Windows does not support `glob` as a standard C library function as that is not part of the C standard. Attempt to emulate that through the use of `FindFirstFileW` and `FindNextFile` to iterate the matching files given a pattern. This should allow us to start enumerating the files as if we had `glob` available.
|
@SimplyDanny - okay, I think that I've addressed the lint issue which means that this should pass now. Once this is merged, we should be able to start investigating and fixing the test failures. |
SimplyDanny
left a comment
SimplyDanny
left a comment
There was a problem hiding this comment.
This is a good start. I'll create a top-level issue later which we can attach sub-issues to in order to collect all the other task necessary to get everything (tests, running the binary, CI, release artifacts, ...) working and set up.
5 participants
This is currently not possible to build on Windows. It requires that SourceKitten changes are merged (jpsim/SourceKitten#769) and some changes to the toolchain that are still in the process of getting merged upstream (swiftlang/swift-package-manager#6573) which depends on a toolchain that is not yet tagged.
It is not possible to build the tests on Windows due to the use of the executable target as a dependency for the tests which results in multiple definitions of
main.This will require a fix for libdispatch (swiftlang/swift-corelibs-libdispatch#791) as well. With that, it seems that I can now swiftlint on Windows as well!