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.
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.
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.
Over the years, SwiftLintFramework had become a fairly massive monolith,
containing over 400 source files with both core infrastructure and
rules.
Architecturally, the rules should rely on the core infrastructure but
not the other way around. There are two exceptions to this:
`custom_rules` and `superfluous_disable_command` which need special
integration with the linter infrastructure.
Now the time has come to formalize this architecture and one way to do
that is to move the core SwiftLint functionality out of
SwiftLintFramework and into a new SwiftLintCore module that the rules
can depend on.
Beyond enforcing architectural patterns, this also has the advantage of
speeding up incremental compilation by skipping rebuilding the core
functionality when iterating on rules.
Because the core functionality is always useful when building rules, I'm
opting to import SwiftLintCore in SwiftLintFramework as `@_exported` so
that it's implicitly available to all files in SwiftLintFramework
without needing to import it directly.
In a follow-up I'll also split the built-in rules and the extra rules
into their own modules. More modularization is possible from there, but
not planned.
The bulk of this PR just moves files from `Source/SwiftLintFramework/*`
to `Source/SwiftLintCore/*`. There are some other changes that can't be
split up into their own PRs:
* Change jazzy to document the SwiftLintCore module instead of
SwiftLintFramework.
* Change imports in unit tests to reflect where code was moved to.
* Update `sourcery` make rule to reflect where code was moved to.
* Create a new `coreRules` array and register those rules with the
registry. This allows the `custom_rules` and
`superfluous_disable_command` rule implementations to remain internal
to the SwiftLintCore module, preventing more implementation details
from leaking across architectural layers.
* Move `RuleRegistry.registerAllRulesOnce()` out of the type declaration
and up one level so it can access rules defined downstream from
SwiftLintCore.
* Make some SwiftLintFramework declarations public
If built-in rules depend on them.
This will allow separating the rules from the core infrastructure in
separate modules in an upcoming PR.
It also helps formalize the API contract for what should be accessible
to rule implementations.
* Exclude extensions from jazzy
The CLI target shouldn't be importing SwiftLintFramework with
`@_spi(TestHelper)`. If the CLI target needs to access something in
SwiftLintFramework, that declaration should be `public`.
This will allow for registering rules that aren't compiled as part of
SwiftLintFramework.
Specifically this will allow us to split the built-in and extra rules
into separate modules, leading to faster incremental compilation when
working on rules since the rest of the framework won't need to be
rebuilt on every compilation.
By adding a `tools/sourcery` script that downloads and runs Sourcery via
Bazel.
Previously, unrelated changes might include modifications to the
generated comment headers because contributors' local versions of
Sourcery would be used, which we don't control.
Also move the CI job to Buildkite where the bazel server is usually
already warmed up and running.
* Trim excess trailing and vertical whitespace
* Move `SwiftyTextTable` dependency into `frameworkDependencies`
* Adjust wording in README around analyzer rules in the `opt_in_rules`
section, since analyzer rules can only go in the `analyzer_rules`
section.
Danny Mösch
Danny Mösch
JP Simard
Keith Bauer
github-actions[bot]
Kim de Vos
Martin Redington
1in1
kyounh12