Swiftlint: illegal instruction: 4 swiftlint on Xcode 11

[Igor-Palaguta]

New Issue Checklist

• [x] Updated SwiftLint to the latest version
• [x] I searched for existing GitHub issues

Describe the bug

On beta 2 everything worked fine, but on Xcode 11 beta 3 swiftlint starts failing with illegal instruction: 4 swiftlint

SwiftLint.build/Script-77CC59392189ADCC00127275.sh: line 9: 34044 Illegal instruction: 4  swiftlint

After commenting opt in rules one by one found that it was because of reduce_into and trailing_closure rules

Complete output when running SwiftLint, including the stack trace and command used

$ swiftlint lint

Linting 'AAAA.swift' (199/1121)
Linting 'AAAA.swift' (200/1121)
Linting 'AAAA.swift' (201/1121)
Linting 'AAAA.swift' (202/1121)
Linting 'AAAA.swift' (203/1121)
Illegal instruction: 4

After commenting:

  #- reduce_into
  #- trailing_closure

• SwiftLint version (run swiftlint version to be sure)?
  0.33.0
• Installation method used (Homebrew, CocoaPods, building from source, etc)?
  package attached to github release
• Paste your configuration file:

opt_in_rules:
  - anyobject_protocol
  - array_init
  - attributes
  - closure_end_indentation
  - closure_spacing
  - collection_alignment
  - contains_over_first_not_nil
  - conditional_returns_on_newline
  - discouraged_object_literal
  - empty_count
  - empty_string
  - empty_xctest_method
  - explicit_init
  - fallthrough
  - fatal_error_message
  - file_header
  - first_where
  - force_unwrapping
  - identical_operands
  - implicit_return
  - joined_default_parameter
  - let_var_whitespace
  - literal_expression_end_indentation
  - legacy_random
  - lower_acl_than_parent
  - modifier_order
  - multiline_arguments
  - multiline_parameters
  - nimble_operator
  - number_separator
  - operator_usage_whitespace
  - overridden_super_call
  - private_action
  - private_outlet
  - prohibited_super_call
  - reduce_into
  - redundant_nil_coalescing
  - redundant_type_annotation
  - single_test_class
  - sorted_first_last
  - sorted_imports
  - static_operator
  - strict_fileprivate
  - strong_iboutlet
  - switch_case_on_newline
  - toggle_bool
  - trailing_closure
  - unavailable_function
  - unneeded_parentheses_in_closure_argument
  - unused_import
  - unused_private_declaration
  - vertical_parameter_alignment_on_call
  - yoda_condition

• Are you using nested configurations? no
  If so, paste their relative paths and respective contents.
• Which Xcode version are you using (check xcode-select -p)?

xcodebuild -version
Xcode 11.0
Build version 11M362v

[Igor-Palaguta]

[marcelofabri]

Can you provide a sample snippet that triggers the issue when linted?

[Igor-Palaguta]

It fails in raw strings with properties inside interpolation.

import XCTest

final class Class: XCTestCase {
    func testA() {
        let data = Data(#"{"status":100, "code":\#(a.code), "message": "failure"}"#.utf8)
    }
}

[jpsim]

Thanks for sharing steps to reproduce! I have a fix in progress here: https://github.com/jpsim/SourceKitten/pull/602

[jpsim]

Actually, digging more into this, it's a bug in SourceKit in Xcode 11. Will report back when I've filed a bug at bugs.swift.org.

[jpsim]

Filed a bug against SourceKit: https://bugs.swift.org/browse/SR-11099

[Igor-Palaguta]

Thank you!

[Igor-Palaguta]

Same issue in new rule no_space_in_method_call in 0.35.

[lgaches]

Same issue with Xcode 11 Beta 7. Disabling no_space_in_method_call helps.

[Doxxer]

Also, disabling reduce_into opt-in rule helps

[guillaumealgis]

The following opt-in rules can also trigger this bug:

• multiline_function_chains
• trailing_closure
• unused_declaration

Hope this gets fixed upstream soon 🤞🏻

[marcelofabri]

Looks like a fix was pushed to the Swift compiler (https://github.com/apple/swift/pull/26354), but it's unclear when it'll be on official toolchains.

[HevaWu]

Xcode 11 GM with 0.34.0 works for me.
But have the same issue with 0.35.0 😢
Will waiting for the new update .....

[chrisballinger]

I'm also hitting this issue on Xcode 11.1. Not sure what file it's happening on because if I lint just the last file it succeeds.

[chrisballinger]

In my case it was because of a file that ended with a #endif with no accompanying #if. I didn't see the compilation error because SwiftLint was failing before the compilation step in our build process.

[thuss]

SwiftLint 0.34.0 (as opposed to the current 0.35.0) does seem to work fine with Xcode 11.1 so for anyone looking for a short-term workaround you can install 0.34.0 with Homebrew as follows:

brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/6a748c632794a33350c415a4f330800095fdc730/Formula/swiftlint.rb

[jpsim]

It looks like the Swift fix landed in 5.1.1. Closing this.

[broadwaylamb]

I'm still getting this with Swift 5.1.2 (Xcode 11.2) and SwiftLint 0.36.0.

This advice https://github.com/realm/SwiftLint/issues/2793#issuecomment-529342828 helps.

[jpsim]

@broadwaylamb thanks for sharing. Could you share steps to reproduce in a new issue please? Sounds like a different problem.

[broadwaylamb]

@jpsim sure.

I'm using SwiftLint 0.36.0, macOS 10.15.1 with Xcode 11.2 and Swift 5.1.2.

git clone https://github.com/broadwaylamb/OpenCombine.git swiftlint-crash
cd swiftlint-crash
git checkout 806ea79d672c58ef53a79df1e01253332e7af5c6
swiftlint

After linting some files I get:

[1]    27084 illegal hardware instruction  swiftlint

[jpsim]

Thanks for sharing! Turns out that even though the fix https://github.com/apple/swift/pull/27186 was included in the swift-5.1-branch before its version was set to 5.1.1, the fix hasn't actually made it into Xcode's Swift toolchains for 5.1.1 or 5.1.2 😞.

You can work around this by using the latest Swift 5.1 OSS toolchain:

git clone https://github.com/broadwaylamb/OpenCombine.git swiftlint-crash
cd swiftlint-crash
git checkout 806ea79d672c58ef53a79df1e01253332e7af5c6
TOOLCHAIN_DIR=/Library/Developer/Toolchains/swift-5.1-DEVELOPMENT-SNAPSHOT-2019-11-05-a.xctoolchain swiftlint

[dhritzkiv]

Looks like the desired Swift toolchain is in the current App Store version of XCode (11.3.1). Running SwiftLint no longer results in illegal instruction errors.

[bartshappee]

I'm still seeing it with 11.3.1, default toolchain