* 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
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.
Use different issues to make inlineable configurations work in both
scenarios, namely being used standalone and nested as part of another
configuration. In the latter case, finding no values to parse in a raw
configuration is okay, while as a standalone configuration it's not.
This allows to infer names of options from their names in a configuration. CamelCase is translated into snake_case automatically when `apply` is triggered.
* Don't have all `RuleConfiguration`s conform to `InlinableOptionType`. Mark types that must have this capability explicitly. Same for `AcceptableByConfigurationElement`.
* A type being an `InlinableOptionType` doesn't mean it's automatically inlined. This also doesn't depend on the fact of having a name for its key configured any longer. Instead, an `inline` attribute must explicitly be set to `true` in `@ConfigurationElement`.
* Key name inference is optional and can be overwritten by specifying a key name in the attribute.
* Inlined configurations only fail in `apply` when they are really sure that something is odd. Otherwise, they accept to not being updated.
With the binding of configurations to their associated rule types
"unknown configuration" errors can be made more specific mentioning
also the rule's identifier in the printed message.
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.
Danny Mösch
Erik Kerber
JP Simard
Martin Redington
Sam Rayner
wanxiangchwng
Ben P