Disallow newlines in format specifiers of single quoted f- or t-strings

[MichaReiser]

Summary

This PR disallows newlines in format specifiers of single-quoted f- and t-strings. This aligns ruff's behavior with CPython's upstream behavior.

I think we should wait with merging this PR until after the next release so that the formatter can fix-up invalid format specifiers.

Part of #18632

Fixes #18730

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[dylwil3]

Looks good to me!

[dhruvmanila]

I think this might be a bit misleading since it's not the entire format spec where it isn't allowed, it's mainly the literal part of the format spec where it isn't allowed. So, the following is valid

# Newline is inside an expression element of the format spec
f"hello {x:.{y
             }f}"

And, running it on Python 3.13.5:

$ uv run --python 3.13 --no-project python -m ast parser/_.py
Module(
   body=[
      Expr(
         value=JoinedStr(
            values=[
               Constant(value='hello '),
               FormattedValue(
                  value=Name(id='x', ctx=Load()),
                  conversion=-1,
                  format_spec=JoinedStr(
                     values=[
                        Constant(value='.'),
                        FormattedValue(
                           value=Name(id='y', ctx=Load()),
                           conversion=-1),
                        Constant(value='f')]))]))])

While, the following is invalid:

# Newline is inside the literal element of the format spec
f"hello {x:.{y}f
         }"

Running it on Python 3.13.5:

$ uv run --python 3.13 --no-project python -m ast parser/_.py       
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/Users/dhruv/.local/share/uv/python/cpython-3.13.5-macos-aarch64-none/lib/python3.13/ast.py", line 1865, in <module>
    main()
    ~~~~^^
  File "/Users/dhruv/.local/share/uv/python/cpython-3.13.5-macos-aarch64-none/lib/python3.13/ast.py", line 1861, in main
    tree = parse(source, name, args.mode, type_comments=args.no_type_comments)
  File "/Users/dhruv/.local/share/uv/python/cpython-3.13.5-macos-aarch64-none/lib/python3.13/ast.py", line 50, in parse
    return compile(source, filename, mode, flags,
                   _feature_version=feature_version, optimize=optimize)
  File "parser/_.py", line 1
    f"hello {x:.{y}f
    ^
SyntaxError: unterminated f-string literal (detected at line 1)

[dhruvmanila]

I think this is actually just an unterminated f-string literal error and it's not really that the newline isn't allowed.

I don't think we would raise a similar (newline specific) error for something like:

f"hello
world"

which is the same situation except it's the outer literal element.

[MichaReiser]

I'm not sure I follow. The error message is the same as CPython uses. We could clarify it to format spec literal but I'm not sure if that's not more confusing for users (I doubt many know that they even can use interpolations in format specs)

[dhruvmanila]

Oh, I didn't realize that CPython raised a similar error message.

Feel free to ignore my message, it seems I shouldn't be doing late night reviews!

[MichaReiser]

But your comment is 100% correct and matches the implementation. I'm just not sure if using the more precise language here helps users or would be more confusing.

[dhruvmanila]

Looks good!

I'd probably keep the new error as UnterminatedString, refer to my inline comment.