Skip to content

Regression: error messages for literal expressions in invalid places are worse #5989

Closed
@Michael0x2a

Description

@Michael0x2a

After #5947 (basic end-to-end support for literal types) lands, we'll start deferring some of the "invalid type" checks to the semantic analysis layer by wrapping them into a 'RawLiteralType'. This can, in some cases have an unintended side-effect of making some error messages worse. For example, writing T = TypeVar('T', bound=1) previously used to report error messages like "TypeVar 'bound' must be a type"; now they report error messages like E: Invalid type: try using Literal[1] instead?.

We ran into a similar case with 'NewType' -- in that case, we added some special-casing to restore the original error message. We could do the same thing here, and for other similar "type-alias-like" constructs such as NamedTuple or TypedDict.

Alternatively, we could explore adding TypeOfAny.invalid_type as Ivan suggests here -- this could also potentially help us resolve #4030 at the same time.

Note to self: if it looks like literal types aren't going to make it into the next mypy release, we should at least fix this error and/or change any existing errors to make sure we never recommend using 'Literal[...]'. It would be confusing if error messages started talking about literal types before they're actually officially released.

Metadata

Metadata

Assignees

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions