Swiftlint: Shebang being autocorrected with operator whitespace rule

[Mazyod]

New Issue Checklist

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

Bug Report

(swiftlint-autocorrect-fixes) [132] % swiftlint autocorrect --path .devtools --config ../.swiftlint.yml
Loading configuration from '../.swiftlint.yml'
Correcting Swift files at path .devtools
Correcting 'carthage-deps-check.swift' (1/2)
Correcting 'nslocalizedToLocalized.swift' (2/2)
/.../.devtools/carthage-deps-check.swift:1:7 Corrected Operator Usage Whitespace
/.../.devtools/carthage-deps-check.swift:1:11 Corrected Operator Usage Whitespace
Done correcting 2 files!

@@ -1,4 +1,4 @@
-#!/usr/bin/swift
+#!/usr / bin / swift

 import Foundation

Environment

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

disabled_rules:
  - void_return # KEEP
  - unused_closure_parameter # KEEP
  - trailing_comma # KEEP
  - nesting # KEEP
  - closure_parameter_position # KEEP
  - for_where
  - force_try
  - cyclomatic_complexity
  - file_length
  - force_cast
  - function_body_length
  - function_parameter_count
  - todo
  - trailing_whitespace
  - type_body_length
  - identifier_name

opt_in_rules:
  - closure_end_indentation
  - closure_spacing
  - explicit_init
  - first_where
  - multiline_parameters
  - nimble_operator
  - number_separator
  - object_literal
  - operator_usage_whitespace
  - overridden_super_call
  - prohibited_super_call
  - redundant_nil_coalescing
  - vertical_whitespace
  - fatal_error_message
  - implicit_return
  - trailing_closure
  - unneeded_parentheses_in_closure_argument
  - custom_rules
  - line_length

reporter: "xcode"
excluded: # paths to ignore during linting. Takes precedence over `included`.
  - Carthage

object_literal:
  color_literal: false

line_length:
  error: 250
  warning: 180
  ignores_comments: true
  ignores_function_declarations: true

overridden_super_call:
  severity: warning
  excluded: []
  included:
    - "*" # include the default methods that require calling super.
    - mapping(map:)

vertical_whitespace:
  max_empty_lines: 2

type_name:
  min_length: 3
  max_length: # warning and error
    warning: 50
    error: 60
  excluded: iPhone # excluded via string

custom_rules:
  localized_not_NSLocalized: # rule identifier
    included: ".*\\.swift" # regex that defines paths to include during linting. optional.
    name: ".localized instead of NSLocalized" # rule name. optional.
    regex: "(NSLocalizedString)" # matching pattern
    message: "Use .localized instead of NSLocalized" # violation message. optional.
    severity: warning # violation severity. optional.

[Mazyod]

Seemed like a straightforward issue, so I didn't bother with all the required issue checklist, but would be happy to provide more context if it was actually needed.

[marcelofabri]

Which version of SwiftLint are you using? We made a fix for this a while ago (but could be a regression!)

[Mazyod]

@marcelofabri no violations found, but it is being autocorrected anyway. v0.22.0 and v0.23.0.

[marcelofabri]

OK, I could reproduce, thanks!

[marcelofabri]

Fixing this is probably tricker than I thought, since the rules themselves overwrite the files contents. Ideally, we'd special case the shebang so no rule would have to know about it, but I couldn't come up with a simple way to do it. Maybe @jpsim has any ideas?

[Mazyod]

Possible idea:
Hack File.ruleEnabled, and from within, hard code disabling shebangs, or treat a shebang as a LOC with disable flag for all rules.

[marcelofabri]

I think that was the original implementation, but at some point we moved the check to Linter.

[szotyi]

We ran into this issue too. It would be nice to get a fix, so we can have our automations run on all of our swift files. Thanks

[hannesoid]

Seems since #1700 in linting the shebang is ignored, but autocorrect still manipulates the shebang
swiftlint version 0.32.0

[stale[bot]]

This issue has been automatically marked as stale because it has not had any recent activity. Please comment to prevent this issue from being closed. Thank you for your contributions!