Standardize syntax error construction

[ntBre]

Summary

This PR unifies the two different ways Ruff and ty construct syntax errors. Ruff has been storing the primary message in the diagnostic itself, while ty attached the message to the primary annotation:

> ruff check try.py
invalid-syntax: name capture `x` makes remaining patterns unreachable
 --> try.py:2:10
  |
1 | match 42:
2 |     case x: ...
  |          ^
3 |     case y: ...
  |

Found 1 error.
> uvx ty check try.py
WARN ty is pre-release software and not ready for production use. Expect to encounter bugs, missing features, and fatal errors.
Checking ------------------------------------------------------------ 1/1 files                                                                                                 
error[invalid-syntax]
 --> try.py:2:10
  |
1 | match 42:
2 |     case x: ...
  |          ^ name capture `x` makes remaining patterns unreachable
3 |     case y: ...
  |

Found 1 diagnostic

I think there are benefits to both approaches, and I do like ty's version, but I feel like we should pick one (and it might help with #20901 eventually). I slightly prefer Ruff's version, so I went with that. Hopefully this isn't too controversial, but I'm happy to close this if it is.

Note that this shouldn't change any other diagnostic formats in ty because Diagnostic::primary_message was already falling back to the primary annotation message if the diagnostic message was empty. As a result, I think this change will partially resolve the FIXME therein.

Test Plan

Existing tests with updated snapshots

[github-actions]

Diagnostic diff on typing conformance tests

No changes detected when running ty on typing conformance tests ✅

[github-actions]

mypy_primer results

No ecosystem changes detected ✅
No memory usage changes detected ✅

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[codspeed-hq]

CodSpeed Performance Report

Merging #20903 will improve performances by 6.51%

_{Comparing brent/standardize-syntax-error-message (d2e8d76) with main (9de34e7)¹}

Summary

⚡ 1 improvement
✅ 50 untouched

Benchmarks breakdown

	Mode	Benchmark	BASE	HEAD	Change
⚡	WallTime	medium[colour-science]	11.2 s	10.5 s	+6.51%

Footnotes

1. No successful run was found on main (fd568f0) during the generation of this report, so 9de34e7 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[AlexWaygood]

Merging #20903 will improve performances by 6.51%

yeah, that's just a merge race with #20377, judging by the footnote that Codspeed put at the bottom of that comment 😆

[ntBre]

Yes good call, I don't think this should affect performance 😆

[AlexWaygood]

Something like this might be nice here (but not blocking):

error[invalid-syntax]: cannot use an asynchronous comprehension inside of a synchronous comprehension on Python 3.10
 --> src/mdtest_snippet.py:6:19
  |
4 | async def f():
5 |     # error: 19 [invalid-syntax] "cannot use an asynchronous comprehension inside of a synchronous comprehension on Python 3.10 (syntax…
6 |     return {n: [x async for x in elements(n)] for n in range(3)}
  |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^ Syntax was added in 3.11
7 | async def test():
8 |     # error: [not-iterable] "Object of type `range` is not async-iterable"

[ntBre]

I was thinking about that too, or an info sub-diagnostic. I think either option will need something like #20901, though.

[ntBre]

(or just a separate constructor from the very generic invalid_syntax for unsupported syntax errors)