-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New semantic analyzer: only create each SymbolNode once #6300
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
Comments
@JukkaL the problem with |
Just a note to self that we need to fix |
Lowering priority since I believe that we've addresses most issues (but not necessarily all). |
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. |
…nd fix stale upper bounds and values (#6563) This is a follow up for #6527. Fixes #7037 I think this also essentially concludes #6300 This PR prohibits duplicate type variable definitions, previously the second one was silently winning. Also now the first one wins. Note that it didn't require additional attribute on `TypeVarExpr` as I initially though, it looks like we can simple use `s.rvalue.analyzed` for the purpose of linking assignments to variables. This PR also naturally fixes an issue where stale upper bound or value appears in a class that uses the type variable.
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. |
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:
Var
nodesThe text was updated successfully, but these errors were encountered: