The current algorithm is like "collect all included files and subtract all excluded files".
Collecting all included and all excluded files relies on the file system. This can become slow
when the patterns used to exclude files resolve to a large number of files.
The new approach only collects all lintable files and checks them against the exclude patterns.
This can be done by in-memory string-regex-match and does therefore not require file system accesses.
The new implementation also no longer traverses directories that already match an exclude pattern.
(cherry picked from commit 152355e36f)
`URL.path` is not a usable rendering of the path. `URL.path` represents
the URI path. If the path is meant to be consumable as a file path, the
file system representation (aka FSR) must be retrieved.
This improves the file path handling and makes additional tests now
pass.
Co-authored-by: Danny Mösch <danny.moesch@icloud.com>
At least ensure it compiles just fine on Windows.
* build: add CryptoSwift dependency for Windows
* SwiftLintBuiltInRules: treat Windows similar to Linux wrt `NSDataDetector`
* SwiftLintCore: initial pass for Windows support
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.
* swiftlint: add a Windows port
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).
* WIP/SwiftLintCore: port the `glob` function to Windows
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.
If SwiftLint is built from this state using the Swift SDK, we'll get a
large self-contained Linux executable that runs without loading SourceKit.
It can do that by disabling any rule that requires SourceKit.
With `SWIFTLINT_DISABLE_SOURCEKIT` set on a normally (dynamically linked)
binary, the behavior is the same. That's different from the previously
reported more serious warnings.
* Add `RegexConfiguration.ExecutionMode`
To help migrate custom rules to SwiftSyntax. Not wired up yet, just the
configuration parsing and defaults. Will wire it up in the next PR.
The diff looks big, but it's 500+ lines of tests, with ~45 lines of
actually new code.
* Docs
* Address PR feedback
- Add `default` case to ExecutionMode enum instead of using optional
- Change configuration key from `mode` to `execution_mode` for consistency
- Move default execution mode logic to runtime instead of configuration time
- Refactor test functions to use throws instead of do-catch
The protocol will be used to tag rules that may or may not require
SourceKit depending on its configuration. I only expect this to be used
for custom rules as utility to help transition to a fully SwiftSyntax
based approach.
In particular lots of stuff that used to be needed with SourceKit that
we no longer need to keep around.
Identified using Periphery: https://github.com/peripheryapp/periphery
Tasks we perform with Sourcery are rather simple and can be replaced
with a basic collection of files and the generation of lists in the
new `swiftlint-dev` command. This spares contributors from installing
either Sourcery or Bazel.
Ahmad Alfy
Danny Mösch
Danny Mösch
Saleem Abdulrasool
Roman Lavrov
Copilot
Nandhini Subramani
Martin Redington
JP Simard
Keith Bauer
github-actions[bot]