* Make some SwiftLintFramework declarations public
If built-in rules depend on them.
This will allow separating the rules from the core infrastructure in
separate modules in an upcoming PR.
It also helps formalize the API contract for what should be accessible
to rule implementations.
* Exclude extensions from jazzy
A long-standing limitation with SourceKit's "editor open" request is
that we weren't able to get certain tokens, such as braces, brackets and
parentheses.
This meant that this code block would be counted as two lines:
```swift
print(
"hi"
)
```
because the trailing `)` would be treated as a whitespace line.
This meant that our "body length" family of rules that measure the
effective line count of declarations like functions, types or closures
would often significantly under-count the number of content lines in a
body.
Now with SwiftSyntax, we can get all tokens, including the ones
SourceKit was previously ignoring, so we can get much more accurate line
counts when ignoring whitespace and comments.
In addition, we weren't very thorough in how we measured body length.
As an exercise, how many lines long would you say the body of this
function is?
```swift
func hello() {
print("hello")
}
```
Does the body span one line or three lines?
I propose that we consistently ignore the left and right brace lines
when calculating the body line count of these scopes so that we measure
body line counts like this:
```swift
// 1 line
{ print("foo") }
// 1 line
{
}
// 1 line
{
print("foo")
}
// 2 lines
{
let sum = 1 + 2
print(sum)
}
```
Now with those changes in place, in order to keep the default
configuration thresholds to similar levels as before, we need to adjust
them slightly. Here's what I'm suggesting:
|Rule|Before|After|
|-|-|-|
|closure_body_length|20/100|30/100|
|function_body_length|40/100|50/100|
|type_body_length|200/350|250/350|
This is a pretty significant breaking change and I suspect we'll hear
from users who are surprised that some of their declarations now exceed
the rule limits, but I believe this new approach to calculating body
lines is more correct and intuitive compared to what we've had until
now.
OSSCheck is also going to report a bazillion changes with this, which is
expected given the scope of this change.
This option allows for more fine-grained placement of the location
marker for code violating a custom rule, e.g.:
```swift
print("Hello world.")
^~~~~
```
for this `.swiftlint.yml`:
```yaml
custom_rules:
world_preceded_by_hello:
name: "World Preceded by Hello"
included: ".+\\.swift"
message: "The word World predeced by the word hello should be capitalised."
severity: warning
regex: "(?i:hello)\\s+(world)"
match_kinds: [string]
capture_group: 1
```
JP Simard