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.
Failing immediately when a property is invalid is too strict. It feels
sufficient to allow to report an issue but otherwise continue with a default
value instead of stopping execution completely.
The README states that a configuration like `attributes: error` is
valid to only set a different severity level for a rule (the
`attributes` rule here). This was previously only possible for rules
that were accompanied by a plain severity configuration.
I don't think this broke with the automatic parsing code generation.
For some rules it might have worked before, for others not. This change
makes it consistently working for all rules.
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.
Previously this was logged to the console when running tests:
```
[ParseError] Parsing a `DeclSyntax` node from string interpolation produced the following parsing errors.
Set a breakpoint in `SyntaxParseable.logStringInterpolationParsingError()` to debug the failure.
```
And slightly improve the style of the expanded `@SwiftSyntaxRule` macro.
These macros remove some of the boilerplate involved when writing rules.
This change also adds test infrastructure for the macros used within
SwiftLint.
Danny Mösch
Copilot
Vladimir Burdukov
JP Simard