Render unsupported syntax errors in formatter tests #20777

ntBre · 2025-10-08T22:00:21Z

Summary

Based on the suggestion in #20774 (comment), I added rendering of unsupported syntax errors in our format test.

In support of this, I added a DummyFileResolver type to ruff_db to pass to DisplayDiagnostics::new (first commit). Another option would obviously be implementing this directly in the fixtures, but we'd have to import a NotebookIndex somehow; either by depending directly on ruff_notebook or re-exporting it from ruff_db. I thought it might be convenient elsewhere to have a dummy resolver, for example in the parser, where we currently have a separate rendering pipeline copied from our old rendering code in ruff_linter. I also briefly tried implementing a TestDb in the formatter since I noticed the ruff_python_formatter::db module, but that was turning into a lot more code than the dummy resolver.

We could also push this a bit further if we wanted. I didn't add the new snapshots to the black compatibility tests or to the preview snapshots, for example. I thought it was kind of noisy enough (and helpful enough) already, though. We could also use a shorter diagnostic format, but the full output seems most useful once we accept this initial large batch of changes.

Test Plan

I went through the baseline snapshots pretty quickly, but they all looked reasonable to me, with one exception I noted below. I also tested that the case from #20774 produces a new unsupported syntax error.

initially I was going to add this directly in the formatter test fixture file, but we would have to import NotebookIndex from somewhere, so it seemed easiest just to drop this directly in the render module. we could possibly reuse this elsewhere, like in the parser fixtures, which currently have their own syntax error rendering code.

ntBre · 2025-10-08T22:03:26Z

crates/ruff_python_formatter/tests/snapshots/format@expression__binary.py.snap

+496 | /     t"hellooooooooooooooooooooooo \
+497 | |         worlddddddddddddddddddddddddddddddddd"
+    | |______________________________________________^ Cannot use t-strings on Python 3.10 (syntax was added in Python 3.14)


I think this might be an unrelated bug. I would expect this range/underline to look more like:

invalid-syntax: Cannot use t-strings on Python 3.13 (syntax was added in Python 3.14) --> try.py:1:15 | 1 | aaaaaaaaaaa = t"hellooooooooooooooooooooooo \ | _______________^ 2 | | worlddddddddddddddddddddddddddddddddd" + (aaaaaaaaaaaaaaaaaaaaaaaaaa + bbbbbbbbbbbbbbbbbbb) | |______________________________________________^ |

which is what we produce for the unformatted file when I tried it separately.

This looks the same when using ruff check.

invalid-syntax: Cannot use t-strings on Python 3.10 (syntax was added in Python 3.14) --> scratch.py:496:5 | 494 | # wrapped in parentheses. 495 | ( 496 | / t"hellooooooooooooooooooooooo \ 497 | | worlddddddddddddddddddddddddddddddddd" | |______________________________________________^ 498 | + (aaaaaaaaaaaaaaaaaaaaaaaaaa + bbbbbbbbbbbbbbbbbbb) 499 | ) |

The ranges look correct in the playground. So this might be diagnostic rendering specific

github-actions · 2025-10-08T22:14:00Z

`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.

MichaReiser · 2025-10-09T06:08:48Z

crates/ruff_db/src/diagnostic/render.rs

+        static CWD: std::sync::LazyLock<std::path::PathBuf> =
+            std::sync::LazyLock::new(|| std::path::PathBuf::from("."));
+        &CWD


I don't think this is necessary. You can just return Path::new(".")

Ah wow 🤦 It looks like I can simplify the version in the linter too:

ruff/crates/ruff_linter/src/fs.rs

Lines 12 to 15 in 4917e08

#[cfg(target_arch = "wasm32")]

{

static CWD: std::sync::LazyLock<PathBuf> = std::sync::LazyLock::new(|| PathBuf::from("."));

&CWD

I assumed Path::new returned a Path and not a &Path.

MichaReiser · 2025-10-09T06:27:02Z

crates/ruff_python_formatter/tests/snapshots/format@expression__binary.py.snap

+
+
+## Unsupported Syntax Errors
+error[invalid-syntax]


It took me a while to find the message and it seems to be different from what I see in the playground where the primary annotation message comes right after the [invalid-syntax].

I haven't checked the CLI but ideally, the rendering would be the same.

Oh right, that's the difference between Diagnostic::invalid_syntax and the linter's create_syntax_error_diagnostic. I can just copy the latter over here.

MichaReiser · 2025-10-09T06:31:15Z

crates/ruff_python_formatter/tests/snapshots/format@expression__binary.py.snap

+496 | /     t"hellooooooooooooooooooooooo \
+497 | |         worlddddddddddddddddddddddddddddddddd"
+    | |______________________________________________^ Cannot use t-strings on Python 3.10 (syntax was added in Python 3.14)


This looks the same when using ruff check.

invalid-syntax: Cannot use t-strings on Python 3.10 (syntax was added in Python 3.14) --> scratch.py:496:5 | 494 | # wrapped in parentheses. 495 | ( 496 | / t"hellooooooooooooooooooooooo \ 497 | | worlddddddddddddddddddddddddddddddddd" | |______________________________________________^ 498 | + (aaaaaaaaaaaaaaaaaaaaaaaaaa + bbbbbbbbbbbbbbbbbbb) 499 | ) |

The ranges look correct in the playground. So this might be diagnostic rendering specific

MichaReiser · 2025-10-09T06:34:52Z

crates/ruff_python_formatter/tests/snapshots/format@statement__type_alias.py.snap

 ```
+
+
+## Unsupported Syntax Errors


Let's bump the python version for this test to be at least 3.10.

MichaReiser · 2025-10-09T06:44:16Z

crates/ruff_python_formatter/tests/snapshots/format@statement__with.py.snap



+### Unsupported Syntax Errors
+error[invalid-syntax]


Hmm, this is somewhat annoying. What we really want here is to not have new syntax errors. Showing all makes it sort of difficult to spot any accidential syntax errors (when it introduced a new syntax error).

That made me think about fingerprinting again and maybe there's a way to improve the fingerprint.

The formatter shouldn't insert or remove statements. That means, we should be able to match diagnostics to their corresponding statement (include that in the fingerprint). Maybe something like this:

If there are any syntax errors

Traverse the entire AST and build a Vec that contains the range of every statement (in sorted order)

For each syntax error, search for the statement (index) with the smallest range that fully contains the syntax error's range

Use that index as part of the fingerprint

We could also just traverse the AST for every syntax error instead of building a vec first

I guess my thinking was that this looks a lot more annoying here than it will in the future, unless we often add many new inputs with unsupported syntax at once. And we can avoid some of those by splitting up the test cases into version-specific groups as you mention above, but that might be bad for other reasons I haven't run into yet.

I can definitely look more into the fingerprinting though, that was my first thought when running into this yesterday. I think I may have briefly explored something vaguely along these lines even. I was hoping that we could attach the node_index for the AST node to the syntax error when constructing it, at least in tests, but it looks like we just use NONE for the node index in the parser (and often emit syntax errors before we have an AST node anyway).

Yeah, node_index is only initialized in ty. But it's roughly the same as just walking the tree in source order (SourceOrderVisitor) and assigning ids.

The good news is that this seems to work quite well. I think we can probably revert the unsupported syntax error snapshots? It still seems useful to render the new syntax errors as full diagnostics in the Formatted code introduced new unsupported syntax errors message, though, so I think we can keep the resolver.

The bad news is that this uncovered a few more issues in the f-string tests. Not sure about others since that panic aborts the test run.

Actually I guess I looked at this too quickly right before standup. All but one of the new panics is kind of a false positive. In cases like this:

f"foo {'\'bar\''}"

we know it's okay to reuse a quote since that's allowed on the same Python version as escapes. But the fingerprints are different: we lose a "Cannot use an escape sequence" error and gain a "Cannot reuse outer quote character" error.

So I think we should keep the snapshots but restrict them to the new errors detected by the new fingerprinting scheme and remove this hard panic. Maybe that's what you had in mind initially.

Can you say why the fingerprints are different? I would have expected them to be the same because the syntax error belongs to the same statement.

If the fingerprints are different, we could then consider a # invalid-syntax: allow pragma comment to allowlist the few cases where we intentionally want to allow them.

We hash the syntax error kind, which has the same variant (Pep701FString) but a different inner variant (Pep701FString(Backslash) before vs Pep701FString(NestedQuote) after).

I can try playing with the pragma comment.

I feel like there may be a nicer approach here, but I got something working by checking the preceding line for a pragma comment. It works well for the f-string cases. The remaining syntax error snapshots look like bugs that I plan to follow up on.

this inlines the linter's create_syntax_error_diagnostic helper instead of using Diagnostic::invalid_syntax

this gives more useful information than the old message because the old line numbers don't correspond to any code on disk. that's still the case with the new diagnostics, but at least we print the code snippet containing the error, which is easier to match up with the original test case

This reverts commit aa9f30c. with the new fingerprints, we can ignore the syntax errors from using the `type` statement in the input

ntBre · 2025-10-09T15:55:19Z

crates/ruff_python_formatter/tests/snapshots/format@statement__with.py.snap

+### Unsupported Syntax Errors
+error[invalid-syntax]: Cannot use parentheses within a `with` statement on Python 3.8 (syntax was added in Python 3.9)
+   --> with.py:359:6
+    |
+357 |     pass
+358 |
+359 | with (
+    |      ^
+360 |     aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
+361 | ):
+    |


These also appear to be false positives. They seem somewhat related to our discussion here, but I thought that only applied to tuples. These cases are fine on 3.8 besides the runtime errors:

Python 3.8.20 (default, Oct 2 2024, 16:34:12) [Clang 18.1.8 ] on linux Type "help", "copyright", "credits" or "license" for more information. >>> with ( ... 1 + 2 ... ): ... ... Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: __enter__ >>> if True: ... with ( ... 1 ... if True ... else 2 ... ): ... pass ... Traceback (most recent call last): File "<stdin>", line 2, in <module> AttributeError: __enter__

I've looked into this a bit, and I actually don't think we can fix this easily. As noted in the thread linked above, we decided to be a bit more aggressive here and flag tuple cases as syntax errors since they will always cause an error at runtime. But since we parse these two cases the same way:

with (a): ... # ok, even at runtime, if `a` implements the protocol with (a,): ... # runtime error on 3.8, tuple definitely doesn't implement the protocol

we can't differentiate between a single WithItem passed to the context manager, which is okay on 3.8, and a single-item tuple, which we intentionally wanted to flag.

Since 3.8 is EOL and we haven't gotten any user reports, I think we should just accept these snapshots in line with our previous discussion.

I think we could fix it by tracking in try_parse_parenthesized_with_items whether there's a trailing comma (peek for a trailing comma inside the parse_comma_separated_list callback) and then return it as part of try_parse_parenthesized_with_items's result?

But I also agree, I don't think this is worth spending much time on.

I'm looking at this quickly now. parse_comma_separated_list already returns whether there was a trailing comma, so this might be an easy fix.

github-actions · 2025-10-09T18:54:13Z

Diagnostic diff on typing conformance tests

No changes detected when running ty on typing conformance tests ✅

github-actions · 2025-10-09T18:55:15Z

`mypy_primer` results

No ecosystem changes detected ✅
No memory usage changes detected ✅

This is currently stacked on #20777 to remove the panic from introducing the new syntax error tracked in #20774. I also still need to go through the other new deviations to make sure they look reasonable. Summary -- ```shell git clone [email protected]:psf/black.git ../other/black crates/ruff_python_formatter/resources/test/fixtures/import_black_tests.py ../other/black ``` Then ran our tests and accepted the snapshots I had to make a small fix to our tuple normalization logic for `del` statements in the second commit, otherwise the tests were panicking at a changed AST. I think the new implementation is closer to the intention described in the nearby comment anyway, though. The first commit adds the new files, the next three commits make some small fixes to help get the tests running, and then the last commit accepts all of the new snapshots, including the new unsupported syntax error for one f-string example, tracked in #20774. Test Plan -- Newly imported tests

MichaReiser

Nice, I like this a lot more. I think there's a question whether we want to render the unsupported syntax errors (I'm leaning towards that) or have the pragma comment. I do find having both a bit confusing because it's unclear when I'm supposed to use which.

crates/ruff_python_formatter/tests/fixtures.rs

MichaReiser · 2025-10-10T06:10:58Z

crates/ruff_python_formatter/tests/snapshots/format@expression__fstring.py.snap

+
+
+### Unsupported Syntax Errors
+error[invalid-syntax]: Cannot use an escape sequence (backslash) in f-strings on Python 3.10 (syntax was added in Python 3.12)


Are these only the syntax errors that weren't suppressed with invalid-syntax allowed? I'm asking because it's not entirely clear to me when I'm supposed to use invalid-syntax vs when it's okay to just tolerate the invalid syntax errors.

I think I'd either keep panicking in the presence of an invalid syntax error that isn't explicitly suppressed with an invalid-syntax pragma comment or render them:

The risk I see with the pragma comments is that it might unintentionally suppress more syntax errors than I intended (e.g. in the with test case, I might allow invalid-syntax errors to suppress the diagnostics for 3.8, but then introduce an error for 3.9). On the other hand, it makes it very clear that unsupported syntax errors need to be fixed before a PR is merged (or they need to be explicitly suppressed).

If we go with rendering the errors, then I think we should add a short paragraph right below Unsupported syntax errors, saying that these need to be fixed unless they're pre-existing syntax errors already present in the source (and not introduced by the formatter).

Yes, we only render the leftover syntax errors that weren't present initially and weren't suppressed with the pragma comment. With the pragma comments, I was thinking we ideally wouldn't tolerate any snapshots, but I didn't want to fix these bugs in the same PR 😅 So I see what you mean, we should go back to panicking instead of snapshotting once these are resolved.

I think we may also be able to print the fingerprint for new errors so that you could include that in the pragma comment, to make them a bit more specific. Or maybe part of the error message would be easier to use, like in mdtests.

But I think I would still lean toward just rendering all of the new errors too and not having the pragma comments. That's a bit simpler and we didn't have many errors to render once we updated the fingerprint filtering anyway.

But I think I would still lean toward just rendering all of the new errors too and not having the pragma comments. That's a bit simpler and we didn't have many errors to render once we updated the fingerprint filtering anyway.

Sounds good to me. Sorry for misdirecting you on the pragma comments

No worries, it was interesting to try out! I'll keep my cleanup commits from this morning and then revert them all, just in case we ever want to resurrect them.

I'm not sure if all those errors are now okay or if some of those are new errors introduced by the formatter. If any of them falls into the latter category, could you add a FIXME to the fixture file above the relevant line?

I thought the errors for line 762 were related to #20774, but it turns out that they're false positives with our syntax error detection instead. I'll add the FIXME and open a separate issue.

MichaReiser

Very nice find and thanks for taking the time to make our formatter test suite more robust!

MichaReiser · 2025-10-12T05:49:37Z

crates/ruff_python_formatter/tests/fixtures.rs

+        self.nodes
+            .iter()
+            .enumerate()
+            .filter(|(_, node)| node.contains_range(range))
+            .min_by_key(|(_, node)| node.len())
+            .expect("Expected an enclosing node in the AST")
+            .0


I'm fine with this as I don't think it matters much. But if you're interested. Here's an example using partition_point to find the first node that starts at or before a given offset.

ruff/crates/ruff_python_trivia/src/comment_ranges.rs

Lines 39 to 41 in 6ef72e7

let start = self

.raw

.partition_point(|comment| comment.start() < range.start());

Ah okay, thank you! I found the examples above that using binary_search_by, but partition_point is good to know about.

I think I'll just leave it as-is for now if it doesn't matter too much.

MichaReiser · 2025-10-12T05:51:05Z

crates/ruff_python_formatter/tests/snapshots/format@expression__fstring.py.snap

+
+
+### Unsupported Syntax Errors
+error[invalid-syntax]: Cannot use an escape sequence (backslash) in f-strings on Python 3.10 (syntax was added in Python 3.12)


I'm not sure if all those errors are now okay or if some of those are new errors introduced by the formatter. If any of them falls into the latter category, could you add a FIXME to the fixture file above the relevant line?

MichaReiser · 2025-10-12T05:56:49Z

crates/ruff_python_formatter/tests/snapshots/format@statement__with.py.snap

+### Unsupported Syntax Errors
+error[invalid-syntax]: Cannot use parentheses within a `with` statement on Python 3.8 (syntax was added in Python 3.9)
+   --> with.py:359:6
+    |
+357 |     pass
+358 |
+359 | with (
+    |      ^
+360 |     aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa + bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
+361 | ):
+    |


I think we could fix it by tracking in try_parse_parenthesized_with_items whether there's a trailing comma (peek for a trailing comma inside the parse_comma_separated_list callback) and then return it as part of try_parse_parenthesized_with_items's result?

But I also agree, I don't think this is worth spending much time on.

This PR resolves the issue noticed in #20777 (comment). Namely, cases like this were being flagged as syntax errors despite being perfectly valid on Python 3.8: ```pycon Python 3.8.20 (default, Oct 2 2024, 16:34:12) [Clang 18.1.8 ] on linux Type "help", "copyright", "credits" or "license" for more information. >>> with (open("foo.txt", "w")): ... ... Ellipsis >>> with (open("foo.txt", "w")) as f: print(f) ... <_io.TextIOWrapper name='foo.txt' mode='w' encoding='UTF-8'> ``` The second of these was already allowed but not the first: ```shell > ruff check --target-version py38 --ignore ALL - <<EOF with (open("foo.txt", "w")): ... with (open("foo.txt", "w")) as f: print(f) EOF invalid-syntax: Cannot use parentheses within a `with` statement on Python 3.8 (syntax was added in Python 3.9) --> -:1:6 | 1 | with (open("foo.txt", "w")): ... | ^ 2 | with (open("foo.txt", "w")) as f: print(f) | Found 1 error. ``` There was some discussion of related cases in #16523 (comment), but it seems I overlooked the single-element case when examining tuple special cases. This PR also removes the existing false positive for tuples that we intentionally accepted there. If I'm understanding correctly, it turns out that we didn't need to modify the parser, and cases like: ```python with (a, b, c) as foo: ... # parses but fails at runtime, tuple doesn't have __enter__ ``` and ```

This is currently stacked on #20777 to remove the panic from introducing the new syntax error tracked in #20774. I also still need to go through the other new deviations to make sure they look reasonable. Summary -- ```shell git clone [email protected]:psf/black.git ../other/black crates/ruff_python_formatter/resources/test/fixtures/import_black_tests.py ../other/black ``` Then ran our tests and accepted the snapshots I had to make a small fix to our tuple normalization logic for `del` statements in the second commit, otherwise the tests were panicking at a changed AST. I think the new implementation is closer to the intention described in the nearby comment anyway, though. The first commit adds the new files, the next three commits make some small fixes to help get the tests running, and then the last commit accepts all of the new snapshots, including the new unsupported syntax error for one f-string example, tracked in #20774. Test Plan -- Newly imported tests

…20846) This PR resolves the issue noticed in #20777 (comment). Namely, cases like this were being flagged as syntax errors despite being perfectly valid on Python 3.8: ```pycon Python 3.8.20 (default, Oct 2 2024, 16:34:12) [Clang 18.1.8 ] on linux Type "help", "copyright", "credits" or "license" for more information. >>> with (open("foo.txt", "w")): ... ... Ellipsis >>> with (open("foo.txt", "w")) as f: print(f) ... <_io.TextIOWrapper name='foo.txt' mode='w' encoding='UTF-8'> ``` The second of these was already allowed but not the first: ```shell > ruff check --target-version py38 --ignore ALL - <<EOF with (open("foo.txt", "w")): ... with (open("foo.txt", "w")) as f: print(f) EOF invalid-syntax: Cannot use parentheses within a `with` statement on Python 3.8 (syntax was added in Python 3.9) --> -:1:6 | 1 | with (open("foo.txt", "w")): ... | ^ 2 | with (open("foo.txt", "w")) as f: print(f) | Found 1 error. ``` There was some discussion of related cases in #16523 (comment), but it seems I overlooked the single-element case when flagging tuples. As suggested in the other thread, we can just check if there's more than one element or a trailing comma, which will cause the tuple parsing on <=3.8 and avoid the false positives.

This is currently stacked on #20777 to remove the panic from introducing the new syntax error tracked in #20774. I also still need to go through the other new deviations to make sure they look reasonable. Summary -- ```shell git clone [email protected]:psf/black.git ../other/black crates/ruff_python_formatter/resources/test/fixtures/import_black_tests.py ../other/black ``` Then ran our tests and accepted the snapshots I had to make a small fix to our tuple normalization logic for `del` statements in the second commit, otherwise the tests were panicking at a changed AST. I think the new implementation is closer to the intention described in the nearby comment anyway, though. The first commit adds the new files, the next three commits make some small fixes to help get the tests running, and then the last commit accepts all of the new snapshots, including the new unsupported syntax error for one f-string example, tracked in #20774. Test Plan -- Newly imported tests

…tity * origin/main: (24 commits) Update Python compatibility from 3.13 to 3.14 in README.md (#20852) [syntax-errors]: break outside loop F701 (#20556) [ty] Treat `Callable`s as bound-method descriptors in special cases (#20802) [ty] Do not bind self to non-positional parameters (#20850) Fix syntax error false positives on parenthesized context managers (#20846) [ty] Remove 'pre-release software' warning (#20817) Render unsupported syntax errors in formatter tests (#20777) [ty] Treat functions, methods, and dynamic types as function-like `Callable`s (#20842) [ty] Move logic for `super()` inference to a new `types::bound_super` submodule (#20840) [ty] Fix false-positive diagnostics on `super()` calls (#20814) [ty] Move `class_member` to `member` module (#20837) [`ruff`] Use DiagnosticTag for more flake8 and numpy rules (#20758) [ty] Prefer declared base class attribute over inferred attribute on subclass (#20764) [ty] Log files that are slow to type check (#20836) Update cargo-bins/cargo-binstall action to v1.15.7 (#20827) Update CodSpeedHQ/action action to v4.1.1 (#20828) Update Rust crate pyproject-toml to v0.13.7 (#20835) Update Rust crate anstream to v0.6.21 (#20829) Update Rust crate libc to v0.2.177 (#20832) Update Rust crate memchr to v2.7.6 (#20834) ...

* main: (25 commits) [ty] Diagnostic for generic classes that reference typevars in enclosing scope (#20822) Update Python compatibility from 3.13 to 3.14 in README.md (#20852) [syntax-errors]: break outside loop F701 (#20556) [ty] Treat `Callable`s as bound-method descriptors in special cases (#20802) [ty] Do not bind self to non-positional parameters (#20850) Fix syntax error false positives on parenthesized context managers (#20846) [ty] Remove 'pre-release software' warning (#20817) Render unsupported syntax errors in formatter tests (#20777) [ty] Treat functions, methods, and dynamic types as function-like `Callable`s (#20842) [ty] Move logic for `super()` inference to a new `types::bound_super` submodule (#20840) [ty] Fix false-positive diagnostics on `super()` calls (#20814) [ty] Move `class_member` to `member` module (#20837) [`ruff`] Use DiagnosticTag for more flake8 and numpy rules (#20758) [ty] Prefer declared base class attribute over inferred attribute on subclass (#20764) [ty] Log files that are slow to type check (#20836) Update cargo-bins/cargo-binstall action to v1.15.7 (#20827) Update CodSpeedHQ/action action to v4.1.1 (#20828) Update Rust crate pyproject-toml to v0.13.7 (#20835) Update Rust crate anstream to v0.6.21 (#20829) Update Rust crate libc to v0.2.177 (#20832) ...

…rable * origin/main: (26 commits) [ty] Add separate type for typevar "identity" (#20813) [ty] Diagnostic for generic classes that reference typevars in enclosing scope (#20822) Update Python compatibility from 3.13 to 3.14 in README.md (#20852) [syntax-errors]: break outside loop F701 (#20556) [ty] Treat `Callable`s as bound-method descriptors in special cases (#20802) [ty] Do not bind self to non-positional parameters (#20850) Fix syntax error false positives on parenthesized context managers (#20846) [ty] Remove 'pre-release software' warning (#20817) Render unsupported syntax errors in formatter tests (#20777) [ty] Treat functions, methods, and dynamic types as function-like `Callable`s (#20842) [ty] Move logic for `super()` inference to a new `types::bound_super` submodule (#20840) [ty] Fix false-positive diagnostics on `super()` calls (#20814) [ty] Move `class_member` to `member` module (#20837) [`ruff`] Use DiagnosticTag for more flake8 and numpy rules (#20758) [ty] Prefer declared base class attribute over inferred attribute on subclass (#20764) [ty] Log files that are slow to type check (#20836) Update cargo-bins/cargo-binstall action to v1.15.7 (#20827) Update CodSpeedHQ/action action to v4.1.1 (#20828) Update Rust crate pyproject-toml to v0.13.7 (#20835) Update Rust crate anstream to v0.6.21 (#20829) ...

ntBre added 3 commits October 8, 2025 17:45

add snapshotting code for unsupported syntax errors

5f5059a

accept snapshots

4917e08

ntBre added formatter Related to the formatter testing Related to testing Ruff itself labels Oct 8, 2025

ntBre commented Oct 8, 2025

View reviewed changes

ntBre marked this pull request as ready for review October 8, 2025 22:16

ntBre requested review from MichaReiser, carljm, dcreager and sharkdp as code owners October 8, 2025 22:16

ntBre removed request for carljm, dcreager and sharkdp October 8, 2025 22:17

MichaReiser reviewed Oct 9, 2025

View reviewed changes

ntBre added 8 commits October 9, 2025 09:03

simplify current directory construction

f394bb3

move the diagnostic message to the header

bcddd82

this inlines the linter's create_syntax_error_diagnostic helper instead of using Diagnostic::invalid_syntax

use 3.12 for type alias tests

aa9f30c

collect node ids to fingerprint syntax errors

f396439

don't panic on new errors, just snapshot them for review

a30cdec

Revert "use 3.12 for type alias tests"

b6b727d

This reverts commit aa9f30c. with the new fingerprints, we can ignore the syntax errors from using the `type` statement in the input

revert now-unrelated snapshot changes

807300b

ntBre commented Oct 9, 2025

View reviewed changes

add support for # invalid-syntax: allow pragma comments

a72cb6a

ntBre mentioned this pull request Oct 9, 2025

Update Black tests #20794

Merged

MichaReiser reviewed Oct 10, 2025

View reviewed changes

ntBre added 6 commits October 10, 2025 10:09

find the narrowest node_id, expect instead of early return

2439bae

use CommentRanges::from directly, remove index dependency

55c9826

avoid building StmtVisitor when there are no syntax errors

8f88450

add info sub-diagnostic suggesting a pragma comment

9781a3b

rough draft of narrowing pragma by trailing diagnostic message

1bde294

revert pragma comment, update sub-diagnostic and docs

50b2969

MichaReiser approved these changes Oct 12, 2025

View reviewed changes

add FIXME for syntax error false positive

e26dce5

ntBre merged commit 975891f into main Oct 13, 2025
38 checks passed

ntBre deleted the brent/render-syntax-errors branch October 13, 2025 14:00

ntBre mentioned this pull request Oct 13, 2025

Fix syntax error false positives on parenthesized context managers #20846

Merged

	#[cfg(target_arch = "wasm32")]
	{
	static CWD: std::sync::LazyLock<PathBuf> = std::sync::LazyLock::new(\|\| PathBuf::from("."));
	&CWD



		### Unsupported Syntax Errors
		error[invalid-syntax]: Cannot use an escape sequence (backslash) in f-strings on Python 3.10 (syntax was added in Python 3.12)

	let start = self
	.raw
	.partition_point(\|comment\| comment.start() < range.start());

Render unsupported syntax errors in formatter tests #20777

Render unsupported syntax errors in formatter tests #20777

Uh oh!

Conversation

ntBre commented Oct 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Test Plan

Uh oh!

ntBre Oct 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Oct 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

ruff-ecosystem results

Linter (stable)

Linter (preview)

Formatter (stable)

Formatter (preview)

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Oct 9, 2025

Diagnostic diff on typing conformance tests

Uh oh!

github-actions bot commented Oct 9, 2025

mypy_primer results

Uh oh!

MichaReiser left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

ntBre commented Oct 8, 2025 •

edited

Loading

ntBre Oct 8, 2025 •

edited

Loading

github-actions bot commented Oct 8, 2025 •

edited

Loading

`ruff-ecosystem` results

`mypy_primer` results