[Autofix error] PIE810 autofix fails when inside f-string: f"{key.startswith('a') or key.startswith('b')}"

[konstin]

In ruff 99a755f, the following snippet causes the autofix PIE810 from the flake8-pie rules to introduce a syntax error:

f"{key.startswith('a') or key.startswith('b')}"

$ ./ruff --no-cache --select PIE810 --fix code.py 

error: Autofix introduced a syntax error. Reverting all changes.

This indicates a bug in `ruff`. If you could open an issue at:

    https://github.com/charliermarsh/ruff/issues/new?title=%5BAutofix%20error%5D

...quoting the contents of `code.py`, the rule codes PIE810, along with the `pyproject.toml` settings and executed command, we'd be very appreciative!

code.py:1:4: PIE810 Call `startswith` once with a `tuple`
Found 1 error.

This was originally discovered in https://github.com/Mojino01/hugging_face/blob/3dae0d7b4fb8d7e9383b893e4e1799191bb2ab7b/src/transformers/models/luke/convert_luke_original_pytorch_checkpoint_to_pytorch.py#L81

[Kirska]

I was digging into this while exploring the code and I think the issue is here:
https://github.com/charliermarsh/ruff/blob/ddd541b1987493a69ef5e8f65ef8030eda6198cd/crates/ruff_python_ast/src/source_code/generator.rs#LL150C40-L150C40

    fn p_str_repr(&mut self, s: &str) {
        let escape = UnicodeEscape::with_preferred_quote(s, self.quote.into());

The rule is using a bool expression, and the generator uses the "preferred quote" to parse constant strings, but in this case, because it's within an f-string, the non-preferred quote is actually what is needed. The generator doesn't have the contextual info to determine that it's within an f-string, as far as I can tell.

Not sure if this problem has been encountered already elsewhere or what the ideal fix would be.

[charliermarsh]

@Kirska - Yeah, that's roughly right! Some cases are a little more nuanced -- we don't necessarily want the non-preferred quote, but rather, whichever quote style wasn't used by the f-string that we're within (the preferred quote is determined by taking the first quote within the file, so it could differ from whatever the f-string is using).

I think we need some way to (1) detect the current quote style if we're in an f-string token, and (2) pass that state down to unparse.

Another option is to avoid autofixing entirely when we're in f-strings, because the grammar is so restrictive.