-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Internal Error due to overloaded generic method? #13515
Labels
Comments
Slightly more minimal repro: from __future__ import annotations
from typing import Protocol, TypeVar, overload
_KT_contra = TypeVar("_KT_contra", contravariant=True)
_VT_co = TypeVar("_VT_co", covariant=True)
_T = TypeVar("_T")
class MappingProtocol(Protocol[_KT_contra, _VT_co]):
@overload
def get(self, key: _KT_contra) -> _VT_co | None: ...
@overload
def get(self, key: _KT_contra, default: _VT_co | _T) -> _VT_co | _T: ...
def do_thing(stuff: MappingProtocol[_KT_contra, _VT_co]) -> None: ...
do_thing({"foo": None}) https://mypy-play.net/?mypy=latest&python=3.10&flags=strict&gist=cebf8bc0e851ea6fa3b52d6d3639096d |
Thanks! I will take a look today. |
So, I was finally able to dig into this issue. What happens?
But, the question is: why does it happen? Right now I still have no idea. |
ilevkivskyi
added a commit
that referenced
this issue
Nov 16, 2022
Fixes #10244 Fixes #13515 This fixes only the crash part, I am going to fix also the embarrassing type variable clash in a separate PR, since it is completely unrelated issue. The crash happens because solver can call `is_suptype()` on the constraint bounds, and those can contain `<Erased>`. Then if it is a generic callable type (e.g. `def [S] (S) -> T` when used as a context is erased to `def [S] (S) -> <Erased>`), `is_subtype()` will try unifying them, causing the crash when applying unified arguments. My fix is to simply allow subtyping between callable types that contain `<Erased>`, we anyway allow checking subtpying between all other types with `<Erased>` components. And this technically can be useful, e.g. `[T <: DerivedGen1[<Erased>], T <: DerivedGen2[<Erased>]]` will be solved as `T <: NonGenBase`. Btw this crash technically has nothing to do with dataclasses, but it looks like there is no other way in mypy to define a callable with generic callable as argument type, if I try: ```python def foo(x: Callable[[S], T]) -> T: ... ``` to repro the crash, mypy instead interprets `foo` as `def [S, T] (x: Callable[[S], T]) -> T`, i.e. the argument type is not generic. I also tried callback protocols, but they also don't repro the crash (at least I can't find a repro), because protocols use variance for subtyping, before actually checking member types.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Report
I ran into an internal error that seems to be related to type inference with an overloaded method. Apologies for the bland description but I don't know mypy internals well enough to debug further.
To Reproduce
Create a py file with the following code and run it through mypy with no arguments:
Running mypy on the file will crash at line 35 (in the
this_causes_mypy_to_crash
method) even on the current dev build:Expected Behavior
Successfully run and tell me if I have any lint errors.
Actual Behavior
Crashes with Internal Error
Environment
mypy.ini
: noneThe text was updated successfully, but these errors were encountered: