Fix crashes caused by typevarlikes defaults in-place modifications#20139
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@hauntsaninja yeah, this looks better indeed. Unfortunately I can't pass I don't think collecting all messages and returning them to the caller would be better - we call |
ilevkivskyi
left a comment
There was a problem hiding this comment.
LG, just one suggestion on test
| from typing_extensions import TypeAlias | ||
|
|
||
| T1 = TypeVar("T1") | ||
| T2 = TypeVar("T2", default=T1) |
There was a problem hiding this comment.
Can you also add a test for something like this?
T1 = TypeVar("T1")
T2 = TypeVar("T2", default=list[T1])(you have a visitor so I guess this should work).
There was a problem hiding this comment.
To expedite things for the release I added a test myself.
There was a problem hiding this comment.
I'm totally swamped atm - I'll go through all pings from mypy on Sat, sorry for holding you back:(
There was a problem hiding this comment.
No worries, I think all remaining release blockers are mypyc-related anyway.
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
Fixes #19185. Fixes #19186.
Replaces #19382 (not closing that yet, need to extract another part related to
applytypefrom there to another PR).When a
TypeVardefaults to anotherTypeVar, that default should already be in scope. Fortunately we already analyze them in the correct order, so the active scope has all the necessary information. This fixes the namespace drift problem because the bound typevars are already adjusted to use the correct namespace, and we do not need to touch their global definitions.I am not super happy about making TypeVarLikeScope impure here - any suggestions? Would passing
self.msgto everybind_newcall look saner?