Added rules filtering options, like in the `rules` subcommand.
<img width="880" alt="generate-docs--help" src="https://user-images.githubusercontent.com/7829589/189372666-2f5aba62-57a1-49dc-9155-c60f9e085984.png">
To achieve reuse with `rules` subcommand:
- extracted filtering logic into `RulesFilter` (and write tests)
- extracted filtering command line parameters into `RulesFilterOptions: ParsableArguments`
Prints out something like this on macOS:
```
Version: 0.49.0-rc.1
Build ID: B43931F3-D096-3704-B41C-FC40673A3F96
```
This can be used to determine if two `swiftlint` executables are
identical.
To support this, we first must use an async entrypoint to the CLI, which
we do by changing the lint and analyze commands to conform to
`AsyncParsableCommand`.
The in order to map over the closures with suspension points, we pull in
CollectionConcurrencyKit as a new dependency.
This change does not touch SwiftLintFramework, only the CLI target.
There is no real benefit for this option. Files and folders to lint/analyze
can be passed to `swiftlint` as last arguments. There cannot be multiple
`--path` arguments. If there is more than one only the last path is considered.
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
* Add Example wrapper in order to display test failures inline when running in Xcode.
* Stop using Swift 5.1-only features so we can compile on Xcode 10.2.
* Wrap strings in Example.
* Add Changelog entry.
* Wrap all examples in Example struct.
* Better and more complete capturing of line numbers.
* Fix broken test.
* Better test traceability.
* Address or disable linting warnings.
* Add documentation comments.
* Disable linter for a few cases.
* Limit mutability and add copy-and-mutate utility functions.
* Limit scope of mutability.
* Add --compile-commands flag
* Implement support for --compile-commands
* Turns out you can't use yaml to read compile_commands.json
* refactor all the things
* Add changelog entry
* formatting
* Add comment and typealiases
* typo
* fix bool logic
* support directory field in compile commands
* remove "directory" field support
* filter compilation database args too
* Remove initial `swiftc` from args
* grammar
In order for rules to collect arbitrary information about all files
being linted, a shared RuleStorage instance is defined in each command
and passed into the linter.
Linting now requires two "passes": once to call collect and populate the
storage (rules that are non-collecting do nothing here), and again to
call validate. The old Linter factory now creates a Prelinter, which can
collect for a file and produce a Linter that orchestrates all the
traditional validation/collection logic.
This design enforces that a file is only validated once it has been
collected; in turn, the file-visiting loop ensures that all files are
collected before the first is validated, so that the storage is fully
populated.
Use storage-backed correct method
Crash if storage for a rule is accessed prematurely
Key FileInfo by File
Rename Prelinter to Linter and Linter to CollectedLinter
Clean up rule protocols such that rule-facing storage methods are actually called
Make RuleStorage a reference type to solve mutating data races
This bumps the minimum version required to build SwiftLint to 4.2. The primary motivating factor to drop support for Swift 4.0-4.1.x is that SwiftLint now uses CryptoSwift, which requires 4.2.
* Add changelog entry
* Remove --allow-warnings flag from CocoaPods commands
* Update CryptoSwift to 0.13.0
* Migrate to Swift 4.2
* Remove CircleCI tests for Swift < 4.2
* Update English and Chinese README
Korean README doesn't yet have a version table like this.
* Update gems
* Add changelog entry for fixed compiler warnings
* Update CocoaPods to 1.6.0.beta.2
To work around https://github.com/CocoaPods/CocoaPods/issues/7708
* Add LintableFilesVisitor
* Move LintCommand logic into LintOrAnalyzeCommand
to prepare for the upcoming analyze command
* Add AnalyzeCommand (not fully implemented yet in SwiftLintFramework)
* Add analyzerRules configuration member
* Add AnalyzerRule protocol
* Pass compiler arguments to validate/correct
* Add requiresFileOnDisk member to RuleDescription
This will be used by AnalyzerRules because they need a file on disk
to pass in the compiler arguments to SourceKit.
* Exclusively run AnalyzerRules when the Linter has compiler arguments
* Enable testing AnalyzerRules in TestHelpers
* Add ExplicitSelfRule
* Update documentation
* Fix `analyze --autocorrect`
* Improve performance of CompilerArgumentsExtractor
* Fix lint command actually running analyze
* Move File operations in TestHelpers into a private extension
* Add analyzer column to rules command and markdown documentation
* Use a Set literal
* Make AnalyzerRule inherit from OptInRule
* Mention analyzer_rules in readme
* Mention that analyzer rules are slow
The MIT license doesn't require that all files be prepended with this
licensing or copyright information. Realm confirmed that they're ok with this
change. This will enable some companies to contribute to SwiftLint and the
date & authorship information will remain accessible via git source control.