This allows specifying a git revision or "commit-ish" that is considered
stable. If specified, SwifLint will attempt to query the git repository
index for files changed since that revision, using only those files as
input as opposed to traversing the file system to collect lintable
files.
* Require Swift 5.3 or higher to build
* Remove Swift Version Support tables from readmes
These weren't exactly accurate because SwiftLint should still work with
older Swift versions long after we update the minimum version of Swift
needed to _build_ the tool. So I doubt this table was very helpful to
anyone.
Try a few things:
1. Sort InclusiveLanguageRule terms since they're a Set and don't have
deteministic ordering (will definitely help)
2. Fetch remote at the beginning of the script (likely to help)
3. Only fetch remote once (likely to help)
4. Sort branch & master output before diffing (unlikely to help)
5. Change diff filter from `d` to `AMRCU` (no idea if it will help)
When a declaration refers to an Objective-C type but doesn't have an
explicit `@objc` attribute.
It would have the string `@objc` embedded in its USR. So add a space so
we only trigger this condition when there's an explicit `@objc`
attribute in the declaration source code.
The triggering example added here didn't trigger before this change.
A colleague was confused by the output of `swiftlint autocorrect`, she
couldn't understand why SwiftLint told her it corrected thousands of
files when she only touched one.
The "Done correcting \(files.count) ..." output made her think that a
change was made on each of the `files`, when really they had only been
inspected.
A good solution would be to adopt a similar approach as the `lint`
command does.
Not being familiar with the codebase, I though a good first step could
have been to tweak the message a bit, making it clearer that the count
printed to the console is the inspected files.
That's because it can currently be difficult to know why a module is
referenced in a file.
To use, run SwiftLint with the environment variable set to the module
whose references you want to log to `stderr`:
SWIFTLINT_LOG_MODULE_USAGE=MyModule swiftlint analyze ...
That's because it can currently be difficult to know why a module is
referenced in a file.
To use, run SwiftLint with the environment variable set to the module
whose references you want to log to `stderr`:
SWIFTLINT_LOG_MODULE_USAGE=MyModule swiftlint analyze ...
JP Simard