-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash introduced in 0.26.0 #2276
Comments
The problem seems to reside in the SourceKitten framework, ironically caused by a force-unwrap. SwiftLint 0.26.0 resolves to SourceKitten 0.21.0. Checking the SourceKitten repo, seems like a crash related to Swift 4.2 was fixed on the 0.21.1 release. SourceKitten 0.21.1 does not seem to be available for SwiftLint (yet), since Yams is locked to 0.20.0.
@jpsim is there an easy way to remove that dependency block to see if 0.21.1 solves this issue? |
The file from our project being processed where SwiftLint crashes is this one (has not been updated in the last 7 months): That file contains a few emoji used for logging purposes, which might be related to the encoding issues causing the crash in SourceKitten. From the call-stack in Xcode, I believe the rule being validated is "no_fallthrough_only". Within that rule, the crash happens in public func validate(file: File,
kind: StatementKind,
dictionary: [String: SourceKitRepresentable]) -> [StyleViolation] {
guard kind == .case,
let length = dictionary.length,
let offset = dictionary.offset,
case let nsstring = file.contents.bridge(),
let range = nsstring.byteRangeToNSRange(start: offset, length: length), // <-- 💥 crash
let colonLocation = findCaseColon(text: nsstring, range: range)
else {
return []
}
... |
It is unlikely that it has anything to do with SourceKitten. The crash is ultimately due to invalid string index conversions (scalar vs cluster vs byte vs UTF‐16 element). Far more likely, something in the logic of the The relevant logic is here, but I could not spot the problem with a quick perusal. |
...but I only see one direct call to Is the stack trace you provided from an build that was optimized? Are there possibly inlined functions not showing? |
I was able to reproduce the problem with this example: switch code {
case 200..<300:
return "\(code) ✅"
default:
break
Weirdly, it doesn't happen if I remove the string interpolation. Also, it looks like the first |
I think this is the same issue as jpsim/SourceKitten#444 which was reported on SourceKit as well: https://bugs.swift.org/browse/SR-6443 |
Yes, you are right, @marcelofabri. I did not think of it at first, but now I remember being confused by SourceKit reporting bizarre numbers around interpolation cases—and I was using it directly, not through SourceKitten. @johnhammerlund, in the meantime disabling |
Great to know, thanks all for jumping on this so quickly. I'd like to keep that rule enabled, so I'll instead refactor the switch body as a workaround to SR-6443. |
As discussed in realm/SwiftLint#2276, there is a SourceKit bug involving switch case annotations when string interpolation is involved, which throws off an underlying unicode conversion when running the new no_fallthrough_only rule and causes a crash. As a workaround, this moves the string interpolation outside of the switch body.
As discussed in realm/SwiftLint#2276, there is a SourceKit bug involving switch case annotations when string interpolation is involved, which throws off an underlying unicode conversion when running the new no_fallthrough_only rule and causes a crash. As a workaround, this moves the string interpolation outside of the switch body.
same for me, and this show-stopper is still not fixed? |
This solution is really working ☝️ thanks @SDGGiesbrecht |
Reproduced this bug with this code enum Foo {
case one
case two
}
func bar(foo: Foo) -> String {
let some = "ru_RU"
switch foo {
case .one:
return "\(some) один"
default:
return "\(some) два"
}
} disabling no_fallthrough_only rule helps to prevent this crash. I noticed that removing spaces in return statements will not trigger the crash PS: reproduced on SwiftLint v 0.28.2 and 0.27 |
Thanks for sharing @Statusgman, I was able to reproduce the crash with that example. Fix in jpsim/SourceKitten#570 |
Fixed in #2487. |
This also happens when |
Or when |
I have same problem with swiftlint 0.43.1
Apple Swift version 5.4 (swiftlang-1205.0.26.9 clang-1205.0.19.55) |
@urajio please open a new issue taking care to fill out the template so we can help. |
New Issue Checklist
There is a similar issue (#2039) but the stack traces seem unrelated
Bug Report
Complete output when running SwiftLint, including the stack trace and command used
Environment
SwiftLint version (run
swiftlint version
to be sure)?0.26.0
Installation method used (Homebrew, CocoaPods, building from source, etc)?
Homebrew
Paste your configuration file:
Note: This crash still occurs when running
swiftlint --enable-all-rules
Are you using nested configurations?
If so, paste their relative paths and respective contents.
No
Which Xcode version are you using (check
xcode-select -p
)?Xcode 9.4.1, active developer directory is set to
/Applications/Xcode.app/Contents/Developer
Do you have a sample that shows the issue?
Not yet sure about the exact source of the crash, but this exact failure can be observed here: https://travis-ci.org/mindbody/Conduit
The issue specifically started happening once SwiftLint was updated from 0.25.1 to 0.26.0.
Crash log:
The text was updated successfully, but these errors were encountered: