-
Notifications
You must be signed in to change notification settings - Fork 77
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
core: add TypeVarConstraint, and use in irdl_to_attr_constraint #3443
base: main
Are you sure you want to change the base?
Conversation
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3443 +/- ##
==========================================
- Coverage 90.33% 90.31% -0.02%
==========================================
Files 464 464
Lines 58076 58215 +139
Branches 5552 5555 +3
==========================================
+ Hits 52463 52577 +114
- Misses 4184 4210 +26
+ Partials 1429 1428 -1 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
What was the status on this? Is this still the approach we want to take? |
I'm feeling a bit stuck... There are a few problems still remaining, one of which is that I couldn't hack the whole lazy get/set tyoe variable, so we may have to deal with this as a temporary measure. The other problem is with the type system, where it seems like for this to really make sense we would need to ask all clients to enable experimental Pyright type checking. I had a chat with Mathieu and he is fine with this, I'll raise this at the xDSL meeting this afternoon. I've also not yet completed the migration to |
We currently do not preserve type var information in the ParamDef, meaning that each time that we construct a constraint that specialises a TypeVar used in the definition of an attribute, we reconstruct the definition from scratch. Currently, this means re-parsing the type hints used when defining the attribute, but with a dictionary that maps the TypeVar used to the concrete constraint to use for the attribute's parameter. In order to move away from the type-based ParamDef pattern of defining parametrized attributes, we need to somehow store the information of TypeVars used in the attribute definition. This PR proposes a mechanism based on a new kind of attribute constraint, and uses it to split the existing mechanism into two phases: first constructing the constraint with TypeVars, and then swapping out the TypVars in the result. Upcoming PRs will remove the part where we remove the type parsing for each time that a new constraint for a ParametrizedAttribute is constructed.