Over the years, SwiftLintFramework had become a fairly massive monolith,
containing over 400 source files with both core infrastructure and
rules.
Architecturally, the rules should rely on the core infrastructure but
not the other way around. There are two exceptions to this:
`custom_rules` and `superfluous_disable_command` which need special
integration with the linter infrastructure.
Now the time has come to formalize this architecture and one way to do
that is to move the core SwiftLint functionality out of
SwiftLintFramework and into a new SwiftLintCore module that the rules
can depend on.
Beyond enforcing architectural patterns, this also has the advantage of
speeding up incremental compilation by skipping rebuilding the core
functionality when iterating on rules.
Because the core functionality is always useful when building rules, I'm
opting to import SwiftLintCore in SwiftLintFramework as `@_exported` so
that it's implicitly available to all files in SwiftLintFramework
without needing to import it directly.
In a follow-up I'll also split the built-in rules and the extra rules
into their own modules. More modularization is possible from there, but
not planned.
The bulk of this PR just moves files from `Source/SwiftLintFramework/*`
to `Source/SwiftLintCore/*`. There are some other changes that can't be
split up into their own PRs:
* Change jazzy to document the SwiftLintCore module instead of
SwiftLintFramework.
* Change imports in unit tests to reflect where code was moved to.
* Update `sourcery` make rule to reflect where code was moved to.
* Create a new `coreRules` array and register those rules with the
registry. This allows the `custom_rules` and
`superfluous_disable_command` rule implementations to remain internal
to the SwiftLintCore module, preventing more implementation details
from leaking across architectural layers.
* Move `RuleRegistry.registerAllRulesOnce()` out of the type declaration
and up one level so it can access rules defined downstream from
SwiftLintCore.
This will allow for registering rules that aren't compiled as part of
SwiftLintFramework.
Specifically this will allow us to split the built-in and extra rules
into separate modules, leading to faster incremental compilation when
working on rules since the rest of the framework won't need to be
rebuilt on every compilation.
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.
Since when releasing, many steps depend on the `build`, so we don't want
to clean mid-way through releasing.
Explicitly run `make clean` at the start of `make release`.
* 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>
Previously, it took a very long time to run `make release` since it had
to clean build everything.
With bazel, I'm more confident in incremental builds being solid, so it
now just takes a few seconds if there's anything cached, which is often
the case.
Otherwise this tries to build the SwiftLintTestHelpers module in release
mode, which fails.
Also, to build the actual executable CLI, we can't just
`swift build --target=swiftlint` because that doesn't produce a CLI,
just the object file for the binary. So we have to `swift run`.
* Move generated rule tests to a dedicated GeneratedTests target
* Move integration tests to a dedicated IntegrationTests target
This will improve bazel cacheability by having fewer tests depend on all
lint inputs, which are only needed by the integration tests.
We've tried adding Swift Syntax support to SwiftLint in the past but had to turn it off in https://github.com/realm/SwiftLint/pull/3107 due to distribution and portability issues.
With https://github.com/keith/StaticInternalSwiftSyntaxParser it should be possible to avoid those issues by statically linking the internal Swift syntax parser so it's available no matter where users have Xcode installed on their computer.
By removing all calls to SourceKit (collecting comment commands + checking the current Swift version), there's a really significant performance improvement.
| Framework | Mean [ms] | Min [ms] | Max [ms] | Relative |
|:---|---:|---:|---:|---:|
| SourceKit | 517.8 ± 8.3 | 505.5 | 531.1 | 6.59 ± 0.43 |
| SwiftSyntax | 78.6 ± 5.0 | 72.6 | 92.1 | 1.00 |
In practice, the SourceKit overhead will continue being there for as long as any rule being run is still looking up the SwiftLint syntax map though.
* Disable Swift 5.4 CI jobs
* Remove SwiftLintFramework podspec
I couldn't find a single use in GitHub's search: https://github.com/search?q=SwiftLintFramework+filename%3APodfile+language%3ARuby+language%3ARuby&type=Code
Just not worth maintaining anymore.
* Change package swift tools version to 5.5
* Update docker_test to use Swift 5.5 image
* Clean up old Swift versions in SwiftVersionTests
Even though these older Swift versions should still be supported, these tests
can't be built against those versions so they're useless.
* Run docker commands with `--platform linux/amd64`
* Remove LinuxMain
It looks like tests are discovered dynamically on Linux as of recent
SwiftPM versions.
SwiftPM 5.3 uses the `XCBuild.framework` to generate universal binaries when it receives multiple `--arch` options.
In that case, `--show-bin-path` returns `.build/apple/Products/Release`.
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
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.
There are a lot of libraries dynamically linked, so it's unlikely to
work in most places other than the same Docker image used to build the
binary (latest official Swift Docker image).
It might still be useful if you can guarantee that you'll use this from
that image.
ldd .build/release/swiftlint
linux-vdso.so.1 (0x00007fff38db5000)
libswiftCore.so => /usr/lib/swift/linux/libswiftCore.so (0x00007f11503cd000)
libFoundation.so => /usr/lib/swift/linux/libFoundation.so (0x00007f114fba6000)
libswiftGlibc.so => /usr/lib/swift/linux/libswiftGlibc.so (0x00007f1151264000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f114f987000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f114f784000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f114f580000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f114f1e2000)
libswiftDispatch.so => /usr/lib/swift/linux/libswiftDispatch.so (0x00007f115122b000)
libdispatch.so => /usr/lib/swift/linux/libdispatch.so (0x00007f114ef82000)
libBlocksRuntime.so => /usr/lib/swift/linux/libBlocksRuntime.so (0x00007f114ed7f000)
libFoundationXML.so => /usr/lib/swift/linux/libFoundationXML.so (0x00007f11511d2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f114e98e000)
libicui18nswift.so.65 => /usr/lib/swift/linux/libicui18nswift.so.65 (0x00007f114e463000)
libicuucswift.so.65 => /usr/lib/swift/linux/libicuucswift.so.65 (0x00007f114e062000)
libicudataswift.so.65 => /usr/lib/swift/linux/libicudataswift.so.65 (0x00007f114c3b3000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f114c02a000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f114be12000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1151053000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f114bc0a000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f114b849000)
libicuuc.so.60 => /usr/lib/x86_64-linux-gnu/libicuuc.so.60 (0x00007f114b491000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f114b274000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f114b04e000)
libicudata.so.60 => /usr/lib/x86_64-linux-gnu/libicudata.so.60 (0x00007f11494a5000)
JP Simard
Martin Redington
Keith Smiley
Julio Carrettoni
Tony Arnold
Danny Mösch
Juozas Valančius
Norio Nomura
Dalton Claybrook
Ilias Karim
Marcelo Fabri
