Avoid enforcing native-literals rule within nested f-strings

[charliermarsh]

Summary

The permitted grammar within a nested f-string is really hard to work with. For example, there's typically no way to include quotation marks, unless one of the surrounding strings is triple-quoted? Or something like that. So, again, for example, our rule that flags usages of str() can run into problems when it sees f"{f'{str()}'}" -- there's no way to rewrite str() as "" or ''.

This PR turns off that rule specifically within nested f-strings.

[github-actions]

PR Check Results

Ecosystem

✅ ecosystem check detected no changes.

Benchmark

Linux

group                                      main                                   pr
-----                                      ----                                   --
linter/all-rules/large/dataset.py          1.00     14.0±0.27ms     2.9 MB/sec    1.00     14.0±0.29ms     2.9 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.00      3.4±0.12ms     4.9 MB/sec    1.00      3.4±0.18ms     4.9 MB/sec
linter/all-rules/numpy/globals.py          1.01   435.5±10.13µs     6.8 MB/sec    1.00   432.4±16.64µs     6.8 MB/sec
linter/all-rules/pydantic/types.py         1.00      5.9±0.13ms     4.3 MB/sec    1.01      5.9±0.20ms     4.3 MB/sec
linter/default-rules/large/dataset.py      1.02      6.8±0.23ms     6.0 MB/sec    1.00      6.7±0.19ms     6.1 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.00  1477.7±46.73µs    11.3 MB/sec    1.01  1490.7±62.35µs    11.2 MB/sec
linter/default-rules/numpy/globals.py      1.00    175.3±5.07µs    16.8 MB/sec    1.03   180.8±12.00µs    16.3 MB/sec
linter/default-rules/pydantic/types.py     1.01      3.1±0.10ms     8.2 MB/sec    1.00      3.1±0.11ms     8.3 MB/sec
parser/large/dataset.py                    1.02      5.4±0.13ms     7.6 MB/sec    1.00      5.2±0.15ms     7.8 MB/sec
parser/numpy/ctypeslib.py                  1.02  1047.7±22.71µs    15.9 MB/sec    1.00  1027.2±29.96µs    16.2 MB/sec
parser/numpy/globals.py                    1.05    108.1±4.80µs    27.3 MB/sec    1.00    103.4±3.50µs    28.5 MB/sec
parser/pydantic/types.py                   1.03      2.3±0.07ms    11.0 MB/sec    1.00      2.2±0.07ms    11.4 MB/sec

Windows

group                                      main                                   pr
-----                                      ----                                   --
linter/all-rules/large/dataset.py          1.00     17.3±0.74ms     2.4 MB/sec    1.02     17.6±0.31ms     2.3 MB/sec
linter/all-rules/numpy/ctypeslib.py        1.00      4.3±0.13ms     3.9 MB/sec    1.01      4.4±0.11ms     3.8 MB/sec
linter/all-rules/numpy/globals.py          1.00   510.4±20.36µs     5.8 MB/sec    1.01   515.3±20.77µs     5.7 MB/sec
linter/all-rules/pydantic/types.py         1.00      7.2±0.25ms     3.5 MB/sec    1.02      7.3±0.17ms     3.5 MB/sec
linter/default-rules/large/dataset.py      1.00      8.5±0.26ms     4.8 MB/sec    1.10      9.4±0.28ms     4.3 MB/sec
linter/default-rules/numpy/ctypeslib.py    1.00  1802.5±57.31µs     9.2 MB/sec    1.08  1942.4±67.37µs     8.6 MB/sec
linter/default-rules/numpy/globals.py      1.00   211.3±11.44µs    14.0 MB/sec    1.06   224.7±15.55µs    13.1 MB/sec
linter/default-rules/pydantic/types.py     1.00      3.9±0.10ms     6.6 MB/sec    1.08      4.2±0.15ms     6.1 MB/sec
parser/large/dataset.py                    1.01      6.7±0.12ms     6.1 MB/sec    1.00      6.7±0.13ms     6.1 MB/sec
parser/numpy/ctypeslib.py                  1.00  1254.2±32.48µs    13.3 MB/sec    1.01  1262.4±53.73µs    13.2 MB/sec
parser/numpy/globals.py                    1.02    129.0±6.44µs    22.9 MB/sec    1.00    127.0±3.90µs    23.2 MB/sec
parser/pydantic/types.py                   1.01      2.9±0.09ms     8.9 MB/sec    1.00      2.8±0.08ms     9.0 MB/sec

[MichaReiser]

This is a pretty bad fix, since we'll still end up using unparse_expr within nested f-strings to format some diagnostics, which means we'll show users code and suggestions that won't quite work. But, our options are pretty limited here.

That seems like a good use case for the Applicability::Manual

[charliermarsh]

Would this require that we go through every rule and add a check for ctx.in_nested_f_string(), and use the appropriate applicability method if so?

[MichaReiser]

Would this require that we go through every rule and add a check for ctx.in_nested_f_string(), and use the appropriate applicability method if so?

Hmm yeah. That sounds annoying and very fragile

[MichaReiser]

Adding additional logic here is problematic because we might now no-longer generate fixes for rules that are otherwise marked as AutofixKind::Always.

[charliermarsh]

Yeah. I'm not sure how else to enforce this though. Any ideas? :/

[MichaReiser]

Not really. The most ideal solution in my view would be to automatically downgrade all fixes to Manual but this is hard today because ruff has no centralized logic collecting all diagnostics (every rule has the liberty to manipulate the diagnostics vec).

[konstin]

I checked 3 of the remaining autofix errors and it seems none of them were f-string related 🎉

[konstin]

non specific nit, is there a reason why we always do backticks inside links?

[T-256]

One note to add here is that most of these will valid syntax with PEP 701 implemented, currently targeted for python 3.12, i.e. we could very ambitiously allow autofixes in f-strings for projects with minimum python version 3.12.

Originally posted by @konstin in #4324 (comment)