Making it about 10x faster, finding some previously missed cases and
fixing some previously wrong corrections.
This pulls in the `Collection.windows(ofCount:)` function from Swift
Algorithms.
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.
* Fix analyzer rules with Xcode 13.3
Looks like starting with Xcode 13.3 / Swift 5.6, cursor info requests
started canceling in-flight requests, so we need to pass
`key.cancel_on_subsequent_request: false` to bypass that.
Analyzer rules on Swift 5.6 are extremely slow, however. Not really
usable right now.
* Run analyzer rules one file at a time
* Add changelog entry
* Improve docstrings for `StringView+SwiftSyntax.swift`
* Move changelog entry to correct section & reword
* Change parameter type from `Int` to `ByteCount`
* Move AbsolutePosition / ByteCount conversion to internal API
* Only warn once if syntax tree cannot be parsed
* Move Syntactic Sugar examples to a dedicated file
* Change SyntacticSugarRuleVisitor from SyntaxAnyVisitor to SyntaxVisitor
* Add `SugaredType` enum to help with the implement `SyntacticSugarRule`
Uses SwiftSyntax 5.5 on Linux when building with Swift 5.5. We use the 5.6 version of
SwiftSyntax when building with Swift 5.5 and 5.6 on macOS because we statically link
`lib_InternalSwiftSyntaxParser` thanks to
https://github.com/keith/StaticInternalSwiftSyntaxParser/releases/tag/5.6.
This keeps SwiftLint binaries portable across machines on macOS, regardless of
_where_ or even _if_ `lib_InternalSwiftSyntaxParser` is installed.
* Run TSan CI job with `--configuration release` to avoid stack overflows
* Add Swift 5.6 CI job
* Fix linker settings
This Fixes case when the right part of the expression is an array or a string
Previously, strings and comments tokens were ignored.
In the current implementation, matching done first and then those are filtered if the operator is within the string token
This was previously attempted in #3342, but produced a bug in the case where `--config` is used to specify a config from outside of the source tree. The `--config` argument wasn't always being used as an override, and was being merged with the config in the source tree. This has now been addressed and reverts the revert done in #3362.
Fixes#3341
Current events have renewed the conversation in our community about the roles of terminology with racist connotations in our software. Many companies and developers are now taking appropriate steps to remove this terminology from their codebases and products. (e.g. [GitHub](https://twitter.com/natfriedman/status/1271253144442253312)) This small rule prevents the use of declarations that contain any of the terms: whitelist, blacklist, master, and slave. It may be appropriate to add more terms to this list now or in the future.
As we discussed here https://github.com/realm/SwiftLint/pull/3325 sometimes current excluding algorithm maybe slower than excluding paths by absolute prefix. So I added option for such cases.
Based on what I've checked it works faster for next scenarios:
- the number of input files is relatively small (e.g. when using `use-script-input-files`) and excluded directories contain relatively big number of lintable files
- the number of excluded directories relatively small (e.g. Pods + ThirdParty) and globs not used
Fixes#3341
When SwiftLint searches for nested configurations and only one file has been passed in via the `paths` argument, SwiftLint returns early after inadvertently comparing the containing directory of the file-to-be-linted to itself. This happens because `rootDirectory` is calculated from `rootPath`, which is set to the file being linted in this scenario.