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.
This provides an alternative to getting syntax kinds from SourceKit. The
mappings aren't 100% equivalent, but this should serve as a useful
compatibility layer.
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
Main goal is to bring implementations, rules and examples closer together.
Another advantage is that the rule's layouts are in line with other
`@SwiftSyntaxRule`s.
After the refactoring, violation messages can be
better adapted to the object causing the issue. Violation positions
should be harmonized and more cases for protocols, subscripts and
deinitializers can be added.
Start with a command that generates a template for a new SwiftSyntax
rule. This tool could remain separate or be merged into the official
binary under a `dev` sub-command at a later point in time.
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.
Ideally, SwiftLintCore would some day only contain components
that are needed to define rules. Consequently, it would be the
only bundle required to import for (external) rule development.
Danny Mösch
Erik Kerber
Chris Brakebill
JP Simard
Martin Redington
Keith Bauer
Dinesh Sharma