The non_optional_string_data_conversion rule was previously limited to only triggering on string literals like "foo".data(using: .utf8), but would not catch variable usage like stringVariable.data(using: .utf8).

This PR adds an optional include_variables configuration option (default: false) that allows the rule to also trigger on variables, properties, function calls, and other non-literal expressions when enabled.

Changes Made

• Added custom configuration: Created NonOptionalStringDataConversionConfiguration in a separate file with include_variables: false by default
• Enhanced visitor logic: Updated the rule to check both string literals (always) and variables (when enabled)
• Integrated examples into rule description: Added comprehensive examples covering string literals, variables, properties, function calls, and chained expressions directly in the rule's description for better documentation
• Updated changelog: Added entry documenting the new option and its behavior

Usage

Default behavior (unchanged for backward compatibility):

"foo".data(using: .utf8)        // ⚠️ Warning
stringVar.data(using: .utf8)    // ✅ No warning

With include_variables enabled:

non_optional_string_data_conversion:
  include_variables: true

"foo".data(using: .utf8)              // ⚠️ Warning
stringVar.data(using: .utf8)          // ⚠️ Warning  
obj.prop.data(using: .utf8)           // ⚠️ Warning
getString().data(using: .utf8)        // ⚠️ Warning
optional?.data(using: .utf8)          // ⚠️ Warning

// Still correctly ignored:
Data("foo".utf8)                      // ✅ Correct usage
string.data(using: .ascii)            // ✅ Non-UTF8 encoding

This addresses the maintainer's suggestion in the issue comments to add an optional feature for variable checking while balancing false positive concerns.

Fixes #6094.

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.