- Make "middle part" `.*` not so greedy with `?`.
- Use `(?!` negative look-ahead to improve matching.
- Added corresponding unit tests.
Co-authored-by: Sergei Shirokov <sshirokov@malwarebytes.com>
* add configuration for missing_docs
* fix MissingDocsRuleConfiguration
* add to changelog
* fix up Config default values and update tests
* use XCTAssertTrue and XCTAssertFalse
* fix line length violation
* finish up unit tests
* rever Package.resolved
* `excludes_extensions` defaults to `true` to skip reporting violations
for extensions with missing documentation comments.
* `excludes_inherited_types` defaults to `true` to skip reporting
violations for inherited declarations, like subclass overrides.
* 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.
* Remove NonPrivateXCTestMembersRule
I accidentally implemented this rule twice. So TestCaseAccessibilityRule
did the same thing but with a bit more behavior. This change deletes
NonPrivateXCTestMembersRule but also ports over the autocorrection from
it to TestCaseAccessibilityRule.
This was extracting from another change that no longer needed it. It
should be helpful for anyone testing custom configuration with their
non-analyzer rules.
I added a random example of something that wasn't previously tested as
an example.
* BREAKING CHANGE: As `OverridenSuperCallConfiguration` is a
publicly-exposed struct, this rename should be considered breaking.
* Fix consoleDescription for OverriddenSuperCallConfiguration
Xcode has supported Swift Package Manager projects natively since Xcode
11, which has been out for over a year, where you can use Xcode by
having it open the `Package.swift` manifest rather than a `.xcodeproj`
or `.xcworkspace`.
I've been primarily developing SwiftLint in Xcode using this approach
for over a year, and despite a few nitpicks I have, it's been a joy to
use.
So I'd like to completely remove the Xcode project along with things
that support it:
* `SwiftLint.xcworkspace`/`SwiftLint.xcodeproj`: Neither of these are
needed if we use `xed .` or `xed Package.swift` to develop SwiftLint
in Xcode.
* `Cartfile`/`Cartfile.private`/`Cartfile.resolved`/`.gitmodules`/`Carthage/`:
These were used to manage dependencies as git submodules for use in
the Xcode workspace, but that's no longer necessary if Xcode delegates
to SwiftPM to manage dependencies for us.
* Some scripts can be simplified, cleaned up or even completely removed.
* **Reduce duplication:** Rather than update dependencies or files in
multiples places, there will only be the package manifest and the
Podfile
* **Reduce merge conflicts:** This hasn't been too bad, but it's
occasionally a pain when trying to land old PRs
* **Reduce development overhead:** No need to manually make sure that
files in the Xcode project are sorted alphabetically
* **Reduce clone time:** No need to run
`git submodules update --init --recursive` anymore
I think this breaks Carthage users that pull in SwiftLintFramework as a
dependency in a Cartfile.
However I can't find any references to [`SwiftLintFramework` in any
`Cartfile` files on GitHub](https://github.com/search?q=swiftlintframework+filename%3ACartfile&type=Code&ref=advsearch&l=&l=)
so this doesn't appear to be worth continuing to maintain.
Resolves https://github.com/realm/SwiftLint/issues/3412
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.
Some attributes are parameterized, such as `@objc(name)`. Previously
these reported `attributes` violations because their contents weren't
included in the configuration, which would just have `@objc`.
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.
This allows custom rules to define an `excluded_match_kinds` array instead of listing out all but one or a few of the `SyntaxKind`s in `match_kinds`. Rules that include both `match_kinds` and `excluded_match_kinds` will be invalid, since there's not an obvious way to resolve the two without an arbitrary priority between them.
JP Simard