Add detection of leading-dot when the contextual type is String to optional_data_string_conversion` rule

[nadeemnali]

Summary

The optional_data_string_conversion rule now detects additional variant patterns of String(decoding:as:)
initialization:

• Direct calls: String(decoding: data, as: UTF8.self) (already supported)
• Type-qualified initializer: String.init(decoding: data, as: UTF8.self) (NEW)
• Leading-dot initializer: let text: String = .init(decoding: data, as: UTF8.self) (NEW)
• Optional implicit leading-dot: let text = .init(decoding: data, as: UTF8.self) (controlled by
  allow_implicit_init config)

Changes

1. Refactored visitor logic (OptionalDataStringConversionRule.swift):

   • Changed from visitPost(_ node: DeclReferenceExprSyntax) to visitPost(_ node: FunctionCallExprSyntax) for
     better detection of all call patterns
   • Added support for detecting String.init(...) (MemberAccessExpr with base String)
   • Added support for detecting leading-dot .init(...) when assigned to a variable with explicit String type
     annotation

2. Added configuration system (new file: OptionalDataStringConversionConfiguration.swift):

   • New configuration option: allow_implicit_init (default: false)
   • When false (default): only flag .init(...) with explicit String type annotation
   • When true: also flag implicit leading-dot .init(...) without type annotation

3. Enhanced rule documentation:

   • Expanded non-triggering examples to cover various String initializer patterns
   • Added triggering examples for String.init(...) and .init(...) with explicit type
   • Added example showing allow_implicit_init configuration option

4. Updated configuration registry (default_rule_configurations.yml):

   • Added allow_implicit_init: false to default configuration

Why

Fixes #6359 where cases like let text: String = .init(decoding: data, as: UTF8.self) were not detected.

Testing

Run the rule's example code with:

swift test --filter OptionalDataStringConversionRule

Or lint against the rule directly:

./.build/debug/swiftlint lint Source/SwiftLintBuiltInRules/Rules/Lint/OptionalDataStringConversionRule.swift

[SwiftLintBot]

	19 Messages
📖	Building this branch resulted in a binary size of 27405.65 KiB vs 27384.09 KiB when built on main (0% larger).
📖	Linting Aerial with this PR took 0.78 s vs 0.78 s on main (0% slower).
📖	Linting Alamofire with this PR took 1.04 s vs 1.04 s on main (0% slower).
📖	Linting Brave with this PR took 7.1 s vs 7.16 s on main (0% faster).
📖	Linting DuckDuckGo with this PR took 26.97 s vs 27.0 s on main (0% faster).
📖	Linting Firefox with this PR took 11.98 s vs 11.97 s on main (0% slower).
📖	Linting Kickstarter with this PR took 8.25 s vs 8.29 s on main (0% faster).
📖	Linting Moya with this PR took 0.46 s vs 0.43 s on main (6% slower).
📖	Linting NetNewsWire with this PR took 2.58 s vs 2.6 s on main (0% faster).
📖	Linting Nimble with this PR took 0.71 s vs 0.66 s on main (7% slower).
📖	Linting PocketCasts with this PR took 7.89 s vs 7.8 s on main (1% slower).
📖	Linting Quick with this PR took 0.46 s vs 0.46 s on main (0% slower).
📖	Linting Realm with this PR took 3.04 s vs 3.0 s on main (1% slower).
📖	Linting Sourcery with this PR took 1.85 s vs 1.87 s on main (1% faster).
📖	Linting Swift with this PR took 4.67 s vs 4.69 s on main (0% faster).
📖	Linting SwiftLintPerformanceTests with this PR took 0.35 s vs 0.33 s on main (6% slower).
📖	Linting VLC with this PR took 1.26 s vs 1.24 s on main (1% slower).
📖	Linting Wire with this PR took 18.6 s vs 18.64 s on main (0% faster).
📖	Linting WordPress with this PR took 12.62 s vs 12.63 s on main (0% faster).

Generated by 🚫 Danger

[SimplyDanny]

Thanks for preparing the PR! Please consider my comments.

[SimplyDanny]

Hey @nadeemnali, is anything blocking you from moving this forward?

[nadeemnali]

Hey @nadeemnali, is anything blocking you from moving this forward?

Hey @SimplyDanny Apologies, I was busy for past weeks, will update the comments ASAP

[nadeemnali]

@SimplyDanny Can you please help me with the danger issue in pipeline, can't seem to find any logs for the failure

[SimplyDanny]

@SimplyDanny Can you please help me with the danger issue in pipeline, can't seem to find any logs for the failure

Danger doesn't like merge commits. Please rebase your branch onto main instead.

[SimplyDanny]

Thanks for addressing my remarks! There is one more thing about allowing .init(...) even without an explicit type optionally.

[nadeemnali]

Hi @SimplyDanny I have updated all the comments, can you please review them