[ty] highlight the relevant argument in type assert error messages #19426

oconnor663 · 2025-07-18T21:34:28Z

Here's a quick before/after summary of the formatting changes (updated after some reverts below):

from ty_extensions import static_assert
static_assert(3 > 4, "custom message")

Before:

error[static-assert-error]: Static assertion error: custom message
 --> test.py:2:1
  |
1 | from ty_extensions import static_assert
2 | static_assert(3 > 4, "custom message")
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |

After:

error[static-assert-error]: Static assertion error: custom message
 --> test.py:2:1
  |
1 | from ty_extensions import static_assert
2 | static_assert(3 > 4, "custom message")
  | ^^^^^^^^^^^^^^-----^^^^^^^^^^^^^^^^^^^
  |               |
  |               Inferred type of argument is `Literal[False]`
  |

oconnor663 · 2025-07-18T21:34:56Z

crates/ty_python_semantic/resources/mdtest/directives/static_assert.md

Is this the right place for this new mdtest file?

I think it could go into type_api.md with the existing tests for static_assert, or if we want to keep it separate because it's all about the diagnostics rather than the functionality, then it could go somewhere under diagnostics?

github-actions · 2025-07-18T21:38:22Z

`mypy_primer` results

No ecosystem changes detected ✅
No memory usage changes detected ✅

carljm

Nice!

carljm · 2025-07-18T22:55:15Z

crates/ty_python_semantic/resources/mdtest/directives/static_assert.md

I think it could go into type_api.md with the existing tests for static_assert, or if we want to keep it separate because it's all about the diagnostics rather than the functionality, then it could go somewhere under diagnostics?

AlexWaygood · 2025-07-19T07:03:01Z

.../resources/mdtest/snapshots/cast.md_-_`cast`_-_The_redundant_`cast`…_(7746465d25c4280a).snap

I think this means that for a multiline cast() call, you'd have to have a type: ignore comment very precisely located to suppress the redundant-cast diagnostic. E.g. this would suppress the diagnostic:

cast( int, very_long_variable_name_splitting_the_call_over_several_lines, # type: ignore )

But this wouldn't, since the range of the suppression comment wouldn't overlap with the primary range of the diagnostic:

cast( # type: ignore int, very_long_variable_name_splitting_the_call_over_several_lines, )

I think that would be very confusing for users, so for this reason, in #18050 (regarding the same issue, but for different diagnostics) I went with a slightly different approach of highlighting the call-arguments range with a secondary annotation but keeping the range of the entire call expression as the diagnostic's range. Some discussion in #18050 (comment)

In the long term, I think it would be great if we could disentangle the concepts of "primary range to be highlighted in diagnostics" and "range in which suppression comments are deemed to apply" so that our diagnostic model doesn't require them to always be the same. But that's not something for this PR!

For the same reasons, I'm not sure we should make any changes to assert_type diagnostics in this PR: we already discussed this issue w.r.t. assert_type diagnostics in #18050 and the changes made in that PR were basically the best we thought we could do without reworking the diagnostics model to disentangle the concepts of "diagnostic suppression range" and "range displayed when the diagnostic is rendered"

AlexWaygood · 2025-07-19T07:04:50Z

crates/ty_python_semantic/src/types/function.rs

                            casted_type.display(db),
                        ));
+                        diag.set_primary_message(format_args!(
+                            "Inferred type is already `{}`",


Hmm, doesn't this just repeat information already presented in the summary line of the diagnostic?

It's not clear to me that anyone will want to `# type: ignore` a `static_assert`, since that's is an internal-test-only function, but we might as well be consistent.

oconnor663 · 2025-07-23T01:19:49Z

@AlexWaygood thanks for the explanation there. I've reverted the changes to all the diagnostics other than for static_assert, and I've made that one use a secondary annotation for consistency with the others (though it's internal and I don't imagine we'll ever want to # type: ignore it). See the edited PR description at the top. I've kept some new snapshot tests for cast, but those are now testing the preexisting behavior. Do you have time to re-review?

AlexWaygood

thank you!

* main: (28 commits) [ty] highlight the argument in `static_assert` error messages (astral-sh#19426) [ty] Infer single-valuedness for enums based on `int`/`str` (astral-sh#19510) [ty] Restructure submodule query around `File` dependency [ty] Make `Module` a Salsa ingredient [ty] Reachability analysis for `isinstance(…)` branches (astral-sh#19503) [ty] Normalize single-member enums to their instance type (astral-sh#19502) [ty] Invert `ty_ide` and `ty_project` dependency (astral-sh#19501) [ty] Implement mock language server for testing (astral-sh#19391) [ty] Detect enums if metaclass is a subtype of EnumType/EnumMeta (astral-sh#19481) [ty] perform type narrowing for places marked `global` too (astral-sh#19381) [ty] Use `ThinVec` for sub segments in `PlaceExpr` (astral-sh#19470) [ty] Splat variadic arguments into parameter list (astral-sh#18996) [`flake8-pyi`] Skip fix if all `Union` members are `None` (`PYI016`) (astral-sh#19416) Skip notebook with errors in ecosystem check (astral-sh#19491) [ty] Consistent use of American english (in rules) (astral-sh#19488) [ty] Support iterating over enums (astral-sh#19486) Fix panic for illegal `Literal[…]` annotations with inner subscript expressions (astral-sh#19489) Move fix suggestion to subdiagnostic (astral-sh#19464) [ty] Implement non-stdlib stub mapping for classes and functions (astral-sh#19471) [ty] Disallow illegal uses of `ClassVar` (astral-sh#19483) ... # Conflicts: # crates/ty_ide/src/goto.rs

* main: [ty] Fix narrowing and reachability of class patterns with arguments (#19512) [ty] Implemented partial support for "find references" language server feature. (#19475) [`flake8-use-pathlib`] Add autofix for `PTH101`, `PTH104`, `PTH105`, `PTH121` (#19404) [`perflint`] Parenthesize generator expressions (`PERF401`) (#19325) [`pep8-naming`] Fix `N802` false positives for `CGIHTTPRequestHandler` and `SimpleHTTPRequestHandler` (#19432) [`pylint`] Handle empty comments after line continuation (`PLR2044`) (#19405) Move concise diagnostic rendering to `ruff_db` (#19398) [ty] highlight the argument in `static_assert` error messages (#19426) [ty] Infer single-valuedness for enums based on `int`/`str` (#19510) [ty] Restructure submodule query around `File` dependency [ty] Make `Module` a Salsa ingredient [ty] Reachability analysis for `isinstance(…)` branches (#19503) [ty] Normalize single-member enums to their instance type (#19502) [ty] Invert `ty_ide` and `ty_project` dependency (#19501) [ty] Implement mock language server for testing (#19391) [ty] Detect enums if metaclass is a subtype of EnumType/EnumMeta (#19481) [ty] perform type narrowing for places marked `global` too (#19381)

Closes astral-sh/ty#209. Before: ``` error[static-assert-error]: Static assertion error: custom message --> test.py:2:1 | 1 | from ty_extensions import static_assert 2 | static_assert(3 > 4, "custom message") | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ``` After: ``` error[static-assert-error]: Static assertion error: custom message --> test.py:2:1 | 1 | from ty_extensions import static_assert 2 | static_assert(3 > 4, "custom message") | ^^^^^^^^^^^^^^-----^^^^^^^^^^^^^^^^^^^ | | | Inferred type of argument is `Literal[False]` | ```

highlight the relevant argument in type assert error messages

4163fd8

oconnor663 requested review from AlexWaygood, carljm, dcreager and sharkdp as code owners July 18, 2025 21:34

oconnor663 commented Jul 18, 2025

View reviewed changes

carljm approved these changes Jul 18, 2025

View reviewed changes

AlexWaygood reviewed Jul 19, 2025

View reviewed changes

AlexWaygood changed the title ~~highlight the relevant argument in type assert error messages~~ [ty] highlight the relevant argument in type assert error messages Jul 19, 2025

AlexWaygood added ty Multi-file analysis & type inference diagnostics Related to reporting of diagnostics. labels Jul 19, 2025

oconnor663 added 3 commits July 22, 2025 18:01

revert changes to assert_never, assert_type, and cast

55e01da

make the static_assert error use a secondary annotation

46591a9

It's not clear to me that anyone will want to `# type: ignore` a `static_assert`, since that's is an internal-test-only function, but we might as well be consistent.

move static_assert snapshots to type_api.md

6fb7eeb

AlexWaygood approved these changes Jul 23, 2025

View reviewed changes

oconnor663 merged commit 88bd829 into main Jul 23, 2025
37 checks passed

oconnor663 deleted the jack/known_function_lints branch July 23, 2025 15:24

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[ty] highlight the relevant argument in type assert error messages #19426

[ty] highlight the relevant argument in type assert error messages #19426

Uh oh!

oconnor663 commented Jul 18, 2025 •

edited

Loading

Uh oh!

oconnor663 Jul 18, 2025

Uh oh!

carljm Jul 18, 2025

Uh oh!

github-actions bot commented Jul 18, 2025 •

edited

Loading

Uh oh!

carljm left a comment

Uh oh!

carljm Jul 18, 2025

Uh oh!

AlexWaygood Jul 19, 2025

Uh oh!

AlexWaygood Jul 19, 2025

Uh oh!

AlexWaygood Jul 19, 2025

Uh oh!

oconnor663 commented Jul 23, 2025 •

edited

Loading

Uh oh!

AlexWaygood left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

[ty] highlight the relevant argument in type assert error messages #19426

[ty] highlight the relevant argument in type assert error messages #19426

Uh oh!

Conversation

oconnor663 commented Jul 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oconnor663 Jul 18, 2025

Choose a reason for hiding this comment

Uh oh!

carljm Jul 18, 2025

Choose a reason for hiding this comment

Uh oh!

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

Uh oh!

mypy_primer results

Uh oh!

carljm left a comment

Choose a reason for hiding this comment

Uh oh!

carljm Jul 18, 2025

Choose a reason for hiding this comment

Uh oh!

AlexWaygood Jul 19, 2025

Choose a reason for hiding this comment

Uh oh!

AlexWaygood Jul 19, 2025

Choose a reason for hiding this comment

Uh oh!

AlexWaygood Jul 19, 2025

Choose a reason for hiding this comment

Uh oh!

oconnor663 commented Jul 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AlexWaygood left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

oconnor663 commented Jul 18, 2025 •

edited

Loading

github-actions bot commented Jul 18, 2025 •

edited

Loading

`mypy_primer` results

oconnor663 commented Jul 23, 2025 •

edited

Loading