[ruff] Fix false positive for complex conversion specifiers in logging-eager-conversion (RUF065)
#21464
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Fixes a false positive in
RUF065whenoct()orhex()are used with conversion specifiers that have complex flags or precision.Fixes #21458.
Problem
The rule incorrectly flagged
oct()andhex()calls as unnecessary when conversion specifiers had flags (0,,+) or precision, which change behavior between%sand%#o/%#x.Approach
Added
has_complex_conversion_specifier()helper to detect complex specifiers (zero-pad with width, blank sign, sign char, or precision) and updatedoct()andhex()checks to skip reporting when the specifier is complex.Test Plan
Added test cases to
RUF065_0.pycovering%06s,% s,%+s, and%.3swithoct()andhex().