These aren't enough to enable `-strict-concurrency=complete` for more
modules, but they address some warnings with that flag on and reduces
the scope of what remains to be migrated.
* Compile with `-strict-concurrency=complete`
Only in Bazel for now, because this is considered an unsafe flag in
SwiftPM which would lead to warnings for downstream consumers of
SwiftLint using SwiftPM.
Some imports of SwiftSyntax need the `@preconcurrency` annotation until
https://github.com/apple/swift-syntax/pull/2322 is available in a
release.
The following SwiftLint libraries have `-strict-concurrency=complete`
applied:
* SwiftLintCoreMacros
* SwiftLintBuiltInRules
* SwiftLintExtraRules
The following SwiftLint libraries don't have the flag applied and need
to be migrated:
* SwiftLintCore
* swiftlint (CLI target)
So really the rules and macros are now being compiled with
`-strict-concurrency=complete`, but the core infrastructure of SwiftLint
is not.
Still, given that Swift 6 will eventually make these warnings errors by
default, it's good to prevent issues from creeping in earlier rather
than later.
* Add CI job to build with strict concurrency
These macros remove some of the boilerplate involved when writing rules.
This change also adds test infrastructure for the macros used within
SwiftLint.
This rule flags functions where the only thing they do is call their
super function and therefore could be omitted. For example:
```swift
override func foo() {
super.foo()
}
```
This can get pretty complex since there are a lot of slight variations
the subclasses' functions can call the superclasses' functions with, but
this covers many of the cases. Ideally this would handle variable
overrides too but it doesn't currently.
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.
Advantages of having typical errors at a common place:
* Error message styling can be harmonized
* Existing messages can be reused
* Overview of prefixes ('error: ', 'warning: ')
* Manage how to print them to the console
Because since it was included in a release a few days ago, we've had
several reports of false positives and so flipping to opt-in is
appropriate so users can determine for themselves if they should enable
the rule.
Danny Mösch
JP Simard
Marcelo Fabri
John Szumski
Tatsuyuki Kobayashi
Martin Redington
Matt Thompson
Keith Smiley
Kasra Babaei
woxtu
Kyle Bashour