[pycodestyle] Handle f-strings properly for invalid-escape-sequence (W605)

[dylwil3]

When fixing an invalid escape sequence in an f-string, each f-string element is analyzed for valid escape characters prior to creating the diagnostic and fix. This allows us to safely prefix with r to create a raw string if no valid escape characters were found anywhere in the f-string, and otherwise insert backslashes.

This fixes a bug in the original implementation: each "f-string part" was treated separately, so it was not possible to tell whether a valid escape character was or would be used elsewhere in the f-string.

Progress towards #11491 but format specifiers are not handled in this PR.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MichaReiser]

This makes sense and roughly matches what we do in the implicit concatenated string formatting.

Do we need to have any special handling for escapes in format specifiers or the debug text parts of an f-string? We don't have to fix this as part of this PR but format specifiers and debug texts were something that caused me a a lot of pain when working on f-string formatting

[dylwil3]

Do we need to have any special handling for escapes in format specifiers or the debug text parts of an f-string? We don't have to fix this as part of this PR but format specifiers and debug texts were something that caused me a a lot of pain when working on f-string formatting

As far as I can tell you can't really put an escape in either of those places: for format specifiers I think that's a syntax error and for debug text I think you could only do that inside a nested string (e.g. f"{'\InHere'=}"), which is handled fine (added test to fixture).

But maybe I missed something so if someone comes up with an example I can do a followup PR.

Thank you for the thoughtful review!

[MichaReiser]

>>> a = 10
>>> f"{a:\xFF}"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code '\xff' for object of type 'int'

I think you can have arbitrary escapes but the above is recognized as a hex string. What you linked to is only the list of standard format specifiers but an object can implement support for arbitrary format specifiers

[dylwil3]

What you linked to is only the list of standard format specifiers but an object can implement support for arbitrary format specifiers

Terrifying.

Yes, this doesn't seem quite right when I make the escape invalid:

➜  cargo run -p ruff -- check tmp.py --no-cache --select W605 --fix --diff
--- tmp.py
+++ tmp.py
@@ -1,2 +1,2 @@
 a = 10
-f"{a:\Xff}"
+rf"{a:\Xff}"

Would fix 1 error.

I'll leave the linked issue open and do a followup PR once I understand better how these things work...

Thank you!