To enforce that `self` identifiers are consistently re-bound to a common
identifier name.
Configure `bind_identifier` to the name you want to use.
Defaults to `self`.
Addresses https://github.com/realm/SwiftLint/issues/2495
And only warn once if it's disabled.
This check is expensive and as more rules move away from SourceKit to
SwiftSyntax, it's increasingly common for rules to not use SourceKit at
all.
In addition, SourceKit crashes used to be a lot more common but I
haven't seen one myself in quite a while.
This change makes it possible to add native custom rules when building
SwiftLint via Bazel (possible as of
https://github.com/realm/SwiftLint/pull/4038).
First, add a local bazel repository where custom rules will be defined
to your project's `WORKSPACE`:
```python
local_repository(
name = "swiftlint_extra_rules",
path = "swiftlint_extra_rules",
)
```
Then in the extra rules directory, add an empty `WORKSPACE` and a
`BUILD` file with the following contents:
```python
filegroup(
name = "extra_rules",
srcs = glob(["*.swift"]),
visibility = ["//visibility:public"],
)
```
To add a rule (for example, `MyPrivateRule`) add the following two
files:
```swift
// ExtraRules.swift
func extraRules() -> [Rule.Type] {
[
MyPrivateRule.self,
]
}
```
```swift
// MyPrivateRule.swift
import SourceKittenFramework
import SwiftSyntax
struct MyPrivateRule: ConfigurationProviderRule {
var configuration = SeverityConfiguration(.error)
init() {}
static let description = RuleDescription(
identifier: "my_private_rule",
name: "My Private Rule",
description: "This is my private rule.",
kind: .idiomatic
)
func validate(file: SwiftLintFile) -> [StyleViolation] {
// Perform validation here...
}
}
```
Then you can reference the rule in your configuration or source files as
though they were built in to the official SwiftLint repo.
This means that you have access to SwiftLintFramework's internal API.
We make no guarantees as to the stability of these internal APIs,
although if you end up using something that gets removed please reach
out and we'll make a best effort to maintain some level of support.
This PR also improves the linter cache on macOS to make it correctly
invalidate previous results when custom native rules are edited. This
even works when doing local development of SwiftLint, where previous it
was necessary to use `--no-cache` when working on SwiftLint, now the
cache should always work.
Co-authored-by: Keith Smiley <keithbsmiley@gmail.com>
This will unblock using Swift Concurrency features and updating to the
latest versions of Swift Argument Parser.
This won't drop support for linting projects with an older toolchain /
Xcode selected, as long as SwiftLint was _built_ with 5.6+ and is
_running_ on macOS 12+. So the main breaking change for end users here
is requiring macOS 12 to run.
However, the upside to using Swift Concurrency features is worth the
breaking change in my opinion. Also being able to stay on recent Swift
Argument Parser releases.
Warns if a SwiftUI Image does not have an accessibility label and is not hidden from accessibility. When this is the case, the image's accessibility label defaults to the name of the image file causing a poor UX.
* Only skip autocorrect on files with errors
* Use other kind of warning so tests succeed on Linux
* Update CHANGELOG.md
Co-authored-by: JP Simard <jp@jpsim.com>
Co-authored-by: JP Simard <jp@jpsim.com>
The idea of this new Analyzer rule is to filter the calls of `map` before they are passed on to the classic ArrayInitRule which does the detailed checking of the lambda function block. The rule makes sure that only the `map` function is considered that is defined by the `Sequence` protocol.
* Add ability to focus on a specific test example
* Update CHANGELOG.md
Co-authored-by: JP Simard <jp@jpsim.com>
* Update CONTRIBUTING.md
Co-authored-by: JP Simard <jp@jpsim.com>
Co-authored-by: JP Simard <jp@jpsim.com>
The option can be used if an example has mainly been added as another test case, but is not suitable
as a user example. User examples should be easy to understand. They should clearly show where and
why a rule is applied and where not. Complex examples with rarely used language constructs or
pathological use cases which are indeed important to test but not helpful for understanding can be
hidden from the documentation with this option.
Ryan Cole
Marcelo Fabri
JP Simard
Danny Mösch
Sara Tavares
Paul Taykalo
Andrés Cecilia Luque