The current algorithm is like "collect all included files and subtract all excluded files".
Collecting all included and all excluded files relies on the file system. This can become slow
when the patterns used to exclude files resolve to a large number of files.
The new approach only collects all lintable files and checks them against the exclude patterns.
This can be done by in-memory string-regex-match and does therefore not require file system accesses.
Ideally, SwiftLintCore would some day only contain components
that are needed to define rules. Consequently, it would be the
only bundle required to import for (external) rule development.
* Compile with `-strict-concurrency=complete`
Only in Bazel for now, because this is considered an unsafe flag in
SwiftPM which would lead to warnings for downstream consumers of
SwiftLint using SwiftPM.
Some imports of SwiftSyntax need the `@preconcurrency` annotation until
https://github.com/apple/swift-syntax/pull/2322 is available in a
release.
The following SwiftLint libraries have `-strict-concurrency=complete`
applied:
* SwiftLintCoreMacros
* SwiftLintBuiltInRules
* SwiftLintExtraRules
The following SwiftLint libraries don't have the flag applied and need
to be migrated:
* SwiftLintCore
* swiftlint (CLI target)
So really the rules and macros are now being compiled with
`-strict-concurrency=complete`, but the core infrastructure of SwiftLint
is not.
Still, given that Swift 6 will eventually make these warnings errors by
default, it's good to prevent issues from creeping in earlier rather
than later.
* Add CI job to build with strict concurrency
And pin the Ruby version to 2.7.5. rbenv was installed on all CI
machines using Homebrew, with Ruby 2.7.5 installed and set as the
global version. The `pre-command` script was also updated on all agents
to add rbenv binaries to the path and run `rbenv init`.
Remove rules_ruby integration and just use rbenv and ruby directly.
By adding a `tools/sourcery` script that downloads and runs Sourcery via
Bazel.
Previously, unrelated changes might include modifications to the
generated comment headers because contributors' local versions of
Sourcery would be used, which we don't control.
Also move the CI job to Buildkite where the bazel server is usually
already warmed up and running.
* Use a binary target for the build tool plugin
* Merge `push_version` and `release` make commands
Instead of running `make push_version "0.2.0: Tumble Dry"` and then
`make release`, now run `make release "0.2.0: Tumble Dry"`, which will
build the release artifacts and update/push the new version to GitHub.
This allows the artifacts to use the new version, update the artifact
bundle checksum in the package manifest, then tag the release.
The Releasing.md instructions were updated to reflect this new workflow.
* Add `SwiftLintSourcePlugin` source plugin for SwiftPM
* Add changelog entry
* Remove SwiftLintSourcePlugin for now
* Build from Source on Linux
* Use a lower-level method of checking if a file is accessible
This shouldn’t trigger sandbox violations, I hope…
* Prevent an infinite recursion of the filesystem root
* Remove unnecessary logging
* Quieten the output so that Xcode only prints violations
* Break up comment to avoid line length warning
* Fix capitalization of Glibc import
Co-authored-by: JP Simard <jp@jpsim.com>
Which previously tried to build the SwiftLintTestHelpers module,
which is a test-only module.
This should fix building with precommit and Mint, both of which assume
you can build the CLI targets in a Swift package with the
`swift build -c release` command.
Danny Mösch
Bradley Mackey
JP Simard
Marcelo Fabri
Keith Smiley
Tony ArnoldandJP Simard