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.
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 likeE: 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_typeas 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.