No way to apply force_unwrap rule in multiline strings

New Issue Checklist

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

Describe the bug

I use multiline strings to capture and log error messages in my app, like so.

// swiftlint:disable:next force_unwrapping
let errorMessage =
"""
Failed to subscribe account \(dependencies.account.email!) to the email list
Reason: \(error.reason)
"""

As you can see with these warnings it seems like the SwiftLint rule is not being applied properly when that's the case, leading to two warnings.

- Superfluous Disable Command Violation: SwiftLint rule 'force_unwrapping' did not trigger a violation in the disabled region; remove the disable command (superfluous_disable_command)
- Force Unwrapping Violation: Force unwrapping should be avoided (force_unwrapping)

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

I would prefer not to add this for privacy reasons.

Environment

• SwiftLint version (run swiftlint version to be sure)?
  0.53.0 (seemingly the latest available version on Homebrew)

• Installation method used (Homebrew, CocoaPods, building from source, etc)?
  Homebrew

• Paste your configuration file:

force_try: warning
force_cast: warning

type_body_length:
 - 200 # warning
 - 300 # error

identifier_name:
  excluded:
    - id
    - Id

opt_in_rules:
  - closing_brace
  - collection_alignment
  - contains_over_filter_count
  - contains_over_filter_is_empty
  - contains_over_first_not_nil
  - contains_over_range_nil_comparison
  - discouraged_optional_boolean
  - duplicate_enum_cases
  - duplicate_imports
  - empty_collection_literal
  - empty_count
  - empty_string
  - fallthrough
  - file_header
  - first_where
  - force_unwrapping
  - implicit_return
  - identical_operands
  - last_where
  - legacy_hashing
  - legacy_multiple
  - let_var_whitespace
  - literal_expression_end_indentation
  - multiline_arguments_brackets
  - multiline_function_chains
  - multiline_literal_brackets
  - modifier_order
  - no_fallthrough_only
  - opening_brace
  - operator_usage_whitespace
  - optional_enum_case_matching
  - override_in_extension
  - prefer_self_type_over_type_of_self
  - prefer_zero_over_explicit_init
  - private_subject
  - private_swiftui_state
  - prohibited_interface_builder
  - prohibited_super_call
  - reduce_into
  - redundant_nil_coalescing
  - redundant_type_annotation
  - return_value_from_void_function
  - self_binding
  - shorthand_optional_binding
  - sorted_first_last
  - sorted_imports
  - static_operator
  - switch_case_on_newline
  - toggle_bool
  - unavailable_function
  - untyped_error_in_catch
  - unused_control_flow_label
  - vertical_parameter_alignment_on_call
  - vertical_whitespace_between_cases
  - vertical_whitespace_closing_braces
  - yoda_condition

disabled_rules: # rule identifiers to exclude from running
  - colon
  - cyclomatic_complexity # i don't even know
  - empty_string
  - file_length # enforce a maximum file length
  - function_body_length # enforce a maximum function body length
  - function_parameter_count # ¯\_(ツ)_/¯ we have some methods that use a lot of parame$
  - large_tuple
  - line_length # enforce a maximum line length
  - nesting
  - type_name # enforce a 3-character minimum type name length
  - identifier_name # variables should start with a lowercase character

analyzer_rules:
  - explicit_self
  - unused_declaration
  - unused_import

custom_rules:
  comments_space:
    name: "Space After Comment"
    regex: '(^ *//\w+)'
    message: "There should be a space after //"
    severity: warning

  empty_line_after_guard:
    name: "Empty Line After Guard"
    regex: '(^ *guard[ a-zA-Z0-9=?.\(\),><!]*\{[ a-zA-Z0-9=?.\(\),><!]*\}\n *(?!(?:return|guard))\S+)'
    message: "There should be an empty line after a guard"
    severity: warning

  empty_line_after_super:
    name: "Empty Line After Super"
    regex: '(^ *super\.[ a-zA-Z0-9=?.\(\)\{\}:,><!]*\n *(?!(?:\}|return))\S+)'
    message: "There should be an empty line after super"
    severity: error

• Are you using nested configurations?
  No

• Which Xcode version are you using (check xcodebuild -version)?
  Xcode 15.0.1

• Do you have a sample that shows the issue? Run echo "[string here]" | swiftlint lint --no-cache --use-stdin --enable-all-rules
  to quickly test if your example is really demonstrating the issue. If your example is more
  complex, you can use swiftlint lint --path [file here] --no-cache --enable-all-rules.

See code above

Thank you so much for the help and the amazing piece of software!

Reproduce the report with the shown multiline Swift string and the force_unwrapping rule, using swiftlint lint --path [file here] --no-cache --enable-all-rules. Trace how the rule handles interpolations and how disable commands determine their region. Done means the inline disable suppresses the force-unwrapping violation without producing a superfluous-disable warning.