file_types_order false positive for file only containing extensions

[samrayner]

New Issue Checklist

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

Describe the bug

A file containing only extensions is flagged as placed amongst the file type(s) 'main_type'.

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

swiftlint lint --path Test.swift --no-cache --enable-all-rules
Linting Swift files at paths Test.swift
Linting 'Test.swift' (1/1)
/Users/samrayner/Desktop/Test.swift:1:1: warning: File Name Violation: File name should match a type or extension declared in the file (if any). (file_name)
/Users/samrayner/Desktop/Test.swift:1:1: warning: File Types Order Violation: An 'extension' should not be placed amongst the file type(s) 'main_type'. (file_types_order)
Done linting! Found 2 violations, 0 serious in 1 file.

//Test.swift
extension Foo {}
extension Bar {
}

NOTE: This only occurs with the above simplified example if the file name is different to the first extended type. Renaming Test.swift to Foo.swift fixes both warnings.

Environment

• SwiftLint version (run swiftlint version to be sure)?
  0.32.0
• Installation method used (Homebrew, CocoaPods, building from source, etc)?
  Homebrew
• Are you using nested configurations?
  No
• Which Xcode version are you using (check xcode-select -p)?
  10.2.1

Non-trivial example that triggers the warning twice (first two extensions):

//RequestHeadersStubs.swift
import Foundation
@testable import API

extension UniversalHeaders: Stubbable {
    internal static func stubbed() -> UniversalHeaders {
        return .init(aPIKey: "")
    }
}

extension StandardHeaders: Stubbable {
    internal static func stubbed() -> StandardHeaders {
        return .init(environment: .design)
    }
}

extension AuthorizationHeaders: Stubbable {
    internal static func stubbed() -> AuthorizationHeaders {
        return .init(environment: .design, authorization: "")
    }
}

[Jeehut]

@samrayner Actually this was the intended behavior as file_type_order was designed with expecting "file_name" being turned on as well. But that is not documented and is probably not a good idea given your code example anyways. So making an exception for cases when the file only contains extensions might be a good idea.

I think the easiest solution to this is to add an early return in this line when none of the fileType attributes in the orderedFileTypeOffsets dictionaries values is mainType. Then we could skip the file_type_order rule entirely if configuration.order contains mainType. (If it doesn't, we should not early-return.)

@samrayner Would you be up to implement this yourself and post a PR? I've tried to lay out how this could be tackled. Just make sure to write a failing-test with your above example first before fixing it so we can ensure this doesn't reappear sometime in the future. Also don't forget to update the Changelog. :)

[samrayner]

Thanks @Dschee! Pull request here: #2754