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.
* Include Linux zip in list of GitHub release binaries
This matches what has been included in recent releases.
* Fix one more Linux zip reference
* Use all 1s for the numbered list in Releasing.md
Markdown renders the numbered list correctly, and this way one can easily reorder the steps
or add new steps without needing to renumber everything.
We were using this lock to guarantee a new ID for every file, but we can
get that benefit by using values that are guaranteed to be unique
without the need for locks, such as a UUID.
By using SourceKit's `index` request to index the entire source file,
we can avoid having to make `cursor-info` requests for every candidate
token in the file, which scales linearly with the number of candiate
tokens.
For the Yams project, this approach improved the total SwiftLint run
time by 4.6x: 7.9 down from 36.8s.
The SourceKit index response doesn't have everything we need to identify
declarations, so we still need to make some `cursor-info` requests,
mostly to detect overrides: protocol conformances and parent class
overrides.
This approach ends up finding more unused declarations because the index
contains more declared USRs than can be found by calling `cursor-info`
on candidate tokens in a file.
---
Remove unused declaration in ArrayInitRule
---
Update package versions
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.
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)
This allows you to pass `@path/to/file` which will be read line by line
for the list of files to lint / analyze. This is useful if you want to
pass a massive list of files which will either exceed arg max, or
break most unix tools if you use script input files + env vars.