You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
New semantic analyzer: only create each SymbolNode once #6300
Currently we can create a symbol node multiple times (once per iteration), which is risky since we don't want to risk having different references to a particular name pointing to different nodes. For example, class-based TypedDict definitions may create multiple TypeInfo objects per definition.
I think that for most things we can treat the definition as complete once we've successfully created a symbol table node, and further iterations would skip the definition, as there's nothing more to do.
Normal class definitions should not have this problem, but we should verify that these work as expected:
@JukkaL the problem with AnyStr I told you about was caused by this. I fixed this for type vars, but we still need to check other node kinds in this list.
We currently allow submodules to be redefined as various different things (see #6828) which breaks these assumptions. It looks like we need another approach for dealing with storing submodules. The current approach is problematic in other ways as well.
I think we have fixed all the cases I am aware. We still do some patching/updating of the existing nodes (replace placeholder types in base classes, alias targets, and variable upper bounds), but we don't re-add symbol table nodes. If we will discover more, we can open dedicated issues.
Activity
ilevkivskyi commentedon Feb 7, 2019
@JukkaL the problem with
AnyStrI told you about was caused by this. I fixed this for type vars, but we still need to check other node kinds in this list.ilevkivskyi commentedon Mar 15, 2019
Just a note to self that we need to fix
TypeVarredefinition by preserving a link to defining assignment (I will make a PR).JukkaL commentedon Jun 12, 2019
Lowering priority since I believe that we've addresses most issues (but not necessarily all).
JukkaL commentedon Jun 12, 2019
We currently allow submodules to be redefined as various different things (see #6828) which breaks these assumptions. It looks like we need another approach for dealing with storing submodules. The current approach is problematic in other ways as well.
New semantic analyzer: Prohibit duplicate type variable definitions a…
ilevkivskyi commentedon Jun 26, 2019
I think we have fixed all the cases I am aware. We still do some patching/updating of the existing nodes (replace placeholder types in base classes, alias targets, and variable upper bounds), but we don't re-add symbol table nodes. If we will discover more, we can open dedicated issues.