Show more precise messages in invalid type expressions

[MatthewMckee4]

Summary

Some error messages are not very specific and could be improved

Test Plan

Not yet sure where to put some tests, but will just test invalid type expressions

[MatthewMckee4]

Im not fully sure where to put tests for the currently unsupported special forms and type qualifiers

[github-actions]

mypy_primer results

No ecosystem changes detected ✅

[AlexWaygood]

Im not fully sure where to put tests for the currently unsupported special forms and type qualifiers

maybe these files?

• https://github.com/astral-sh/ruff/blob/main/crates/red_knot_python_semantic/resources/mdtest/annotations/unsupported_type_qualifiers.md
• https://github.com/astral-sh/ruff/blob/main/crates/red_knot_python_semantic/resources/mdtest/annotations/unsupported_special_forms.md

[MatthewMckee4]

Yeah, i thought that, but we does providing error messages not imply that we are supporting them partially?

[AlexWaygood]

True. We'll need comprehensive test suites covering each special form eventually, so you can create new files for each now if you like! But equally, I don't think it matters too much right now; I'd be inclined to just adjust the prose a little bit in those files saying that we don't fully support them, but we do detect some invalid uses when they appear in type expressions.

[MatthewMckee4]

Okay, will do that then, thanks

[MatthewMckee4]

Tests failing because

def _(
    a: Final
) -> None: ...

raises no error

Ill change it to Final | int.

@AlexWaygood why does this happen exactly?

[AlexWaygood]

@AlexWaygood why does this happen exactly?

That's because we currently only validate that parameter annotations are valid annotation expressions. Bare Final is a valid annotation expression, even though it's not a valid type expression.

You can take a look at the typing spec page here for an explanation of the difference between the two concepts: https://typing.python.org/en/latest/spec/annotations.html#type-and-annotation-expressions. Final is a valid annotation expression but not a valid type expression; Final | int is neither a valid annotation expression nor a valid type expression.

Now, is Final a valid parameter annotation? No! 😄 But the reason it's invalid isn't relevant to the changes you're making here, and we shouldn't attempt to detect the invalidity as part of the Type::in_type_expression() method. At some point, we'll need to add some extra validation specifically for parameter annotations that checks exactly whether the annotation expression is one of the expressions that are disallowed in the specific context of parameter annotations. But we haven't implemented that additional check yet :-)

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MatthewMckee4]

Okay understood. What function infers the type of parameter annotations?

[carljm]

What function infers the type of parameter annotations?

TypeInferenceBuilder::infer_parameter and TypeInferenceBuilder::infer_parameter_with_default both call into TypeInferenceBuilder::infer_optional_annotation_expression to infer the annotated type.

[AlexWaygood]

Looks great, thank you!

[AlexWaygood]

Thanks, this is great!! I pushed a commit to make the match a bit more readable, since it was getting a bit big and the KnownInstance branches were interspersed with some of the other branches