ruff/crates/ty_python_semantic/resources/mdtest/generics
Luca Chiodini bf0bc87f06
Uniformly use "not supported" in diagnostics
Some (most?) diagnostic messages already use the form
"Operator <op> not supported", but others use "Operator <op> unsupported":

https://play.ty.dev/ae13cd3d-531b-4ed3-adea-eba9b0cafb6c
```py
0 + ""
0 < ""
```
> Operator `+` is unsupported between objects of type `Literal[0]` and `Literal[""]` (unsupported-operator) [Ln 1, Col 1]
> Operator `<` is not supported between objects of type `Literal[0]` and `Literal[""]` (unsupported-operator) [Ln 2, Col 1]

This commit uniforms the diagnostic messages, favoring "not supported".
While it is two characters longer, this matches pyright/pyrefly's
messages, is slightly less redundant given that
"unsupported" already appears in the diagnostic's type
(e.g., unsupported-operator), and makes the "not" stand out.

(This commit does not remove all occurrences of "unsupported" in diagnostic messages:
there are still some that e.g. start with "Unsupported <X>".
I think those are acceptable as they are.)
2025-12-11 14:47:50 +01:00
..
legacy Uniformly use "not supported" in diagnostics 2025-12-11 14:47:50 +01:00
pep695 Uniformly use "not supported" in diagnostics 2025-12-11 14:47:50 +01:00
builtins.md [ty] Support using legacy typing aliases for generic classes in type annotations (#18404) 2025-06-03 12:09:51 +01:00
scoping.md [ty] Create a specialization from a constraint set (#21414) 2025-11-19 14:20:33 -05:00
specialize_constrained.md [ty] Fix non-determinism in `ConstraintSet.specialize_constrained` (#21744) 2025-12-03 10:19:39 -05:00