F507: Fix false negative for non-tuple RHS in %-formatting

[RenzoMXD]

Summary

Fixes #24031

F507 (percent-format-positional-count-mismatch) previously only checked tuple right-hand sides in %-format expressions. This meant literal non-tuple values like '%s %s' % 42 were silently ignored.

This PR extends F507 to also flag non-tuple RHS values when the format string expects a different number of positional arguments, using ResolvedPythonType::from() to infer the type of the RHS expression.

What gets flagged now

• Literal values: 42, 3.14, "hello", b"hello", True, None, ..., f"hello {name}"
• Compound expressions with known types: -1, 1 + 2, not x, "a" + "b", 1 if True else 2

What is intentionally NOT flagged

Variables, attribute accesses, subscripts, and calls are skipped because they could be tuples at runtime:

x = (1, 2)
'%s %s' % x  # valid Python — % unpacks tuples

Why ResolvedPythonType

Per reviewer suggestion, using ResolvedPythonType::from() instead of manually matching literal expression types catches more cases (unary ops, binary ops, ternary, etc.) and is more maintainable.

Context

The original implementation only checked Expr::Tuple because List and Set were intentionally removed in #5986 — '%s' % [1, 2, 3] is valid Python (lists aren't unpacked by %). This PR takes the same conservative approach by only flagging cases where we can statically determine the type is not a tuple.

Test plan

• Added test cases for all literal types (int, float, string, bytes, bool, None, ellipsis, f-string) with multiple placeholders
• Added test cases for compound expressions resolved via ResolvedPythonType (unary, binary, boolean, ternary)
• Added test cases for single-placeholder with literal RHS (not flagged)
• Added test cases for variables, attribute access, subscripts, calls, ternary with unknowns, binary ops with unknowns (not flagged)
• All 469 existing pyflakes tests pass

[kaddkaka]

Does this also solve the case where the LHS is an f-string?

f"{banana}" % banana

[RenzoMXD]

No, it doesn't. That's a separate issue.

The LHS check happens in expression.rs:1442 — it only matches Expr::StringLiteral:

if let Expr::StringLiteral(format_string @ ast::ExprStringLiteral { value, .. }) = left.as_ref()

So when the LHS is an f-string (Expr::FString), none of the F50x rules fire at all. My fix only touches the RHS handling within F507.

I will make a separate PR for that.

[RenzoMXD]

@ntBre Could you please review my PR?
I will make another PR that solves the case where the LHS is an f-string.

[kaddkaka]

No, it doesn't. That's a separate issue.

The LHS check happens in expression.rs:1442 — it only matches Expr::StringLiteral:

if let Expr::StringLiteral(format_string @ ast::ExprStringLiteral { value, .. }) = left.as_ref()

So when the LHS is an f-string (Expr::FString), none of the F50x rules fire at all. My fix only touches the RHS handling within F507.

I will make a separate PR for that.

OK, but perhaps a case with 0 placeholders and 1 item in right hand side should be considered.

I'm not sure if this case can be covered without risk of false positive:

"no placeholder" % banana

What happens for this case if banana is an empty tuple? I suppose for this particular case, with a literal string LHS, any use of % (no matters what's on RHS) could give a warning.

[RenzoMXD]

Good point! The current implementation already covers that case — "no placeholder" % 42 would be flagged since num_positional is 0 and a literal counts as 1 substitution (0 != 1).

For "no placeholder" % banana, we intentionally don't flag it because banana could be an empty tuple () at runtime, which would be valid. This is consistent with the conservative approach of only flagging literals where we can be certain about the value.