-
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
misc: use VarConstraint instead of Annotated[ConstraintVar] in operation definitions #3264
misc: use VarConstraint instead of Annotated[ConstraintVar] in operation definitions #3264
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 #3264 +/- ##
=======================================
Coverage 89.98% 89.99%
=======================================
Files 444 444
Lines 55631 55659 +28
Branches 5353 5353
=======================================
+ Hits 50060 50088 +28
+ Misses 4174 4169 -5
- Partials 1397 1402 +5 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice. Not a comprehensive review but I left some comments. Is the constr
field a part of the ParametrizedAttr
superclass?
@@ -1661,13 +1664,25 @@ class ParamOne(ParametrizedAttribute, TypeAttribute, Generic[_T]): | |||
p: ParameterDef[_T] | |||
q: ParameterDef[Attribute] | |||
|
|||
@classmethod |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems overkill for this test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think of tests as another kind of documentation, I feel like they should follow the style of the project unless there's a good reason not to.
|
||
T: ClassVar[VarConstraint[IntegerType | IndexType]] = VarConstraint( | ||
"T", base(IntegerType) | base(IndexType) | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general do we want these constraints to be a visible part of the operation interface? Would it be better to use _T
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What _T
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably not related to the PR but I was suggesting that these ClassVar
s containing the constraints could be private
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah I guess they could be, I tried to modify a minimal amount with these changes.
op = GenericConstraintVarOp.create( | ||
operands=[index_operand], result_types=[i32], attributes={"attribute": i32} | ||
) | ||
with pytest.raises(DiagnosticException): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice for these to match on the error
xdsl/dialects/ltl.py
Outdated
ConstraintVar("T"), | ||
] | ||
T: ClassVar[VarConstraint[Attribute]] = VarConstraint( | ||
"T", AnyOf([Sequence, Property, IntegerType(1, signedness=Signedness.SIGNLESS)]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Signedness.SINGLESS
is the default I believe
xdsl/tools/tblgen_to_py.py
Outdated
ParamAttrConstraint( | ||
IntegerAttr, (AnyAttr(), EqAttrConstraint(IndexType())) | ||
) | ||
IntegerAttr[IndexType].constr(type=IndexTypeConstr) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, ignore the earlier comment
171cec9
to
33bb59f
Compare
33bb59f
to
947c06a
Compare
83ef4b9
to
1c2d964
Compare
Pylance errors: 84 -> 74. Part of #3264
…raints/generic-constraint-var
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚢
lhs = operand_def(ParamOne[T]) | ||
lhs = operand_def(ParamOne[Attribute].constr(p=T)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do have to say, I really dislike the verbosity of this, it will make it harder for newcomers to get started I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it definitely got less pretty. One potential alternative is ParamOneConstr(p=T)
, would you like me to try that instead? It's one more thing to import, but potentially worth the effort.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just tested it locally and that API works and makes Pyright happy, it really doesn't want you to omit the type parameter even if it could be inferred in this case. I'm still inclined towards this more verbose API for the time being, with the hope that Pyright gets smart enough at some point to drop the unnecessary type parameter. We could also file it as a bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about making constr
a staticmethod instead? I just tried it locally and my pyright at least seems happy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it doesn't work for me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you feel about iterating on this after this is merged and Pyright is updated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine with me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://peps.python.org/pep-0696/ also potentially relevant for making this api nicer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I look forward to being able to use the new, shiny APIs. I'm not sure when it would be wise to drop support for older Pythons, according to this calendar 3.10 is supported for another couple of years: https://endoflife.date/python
…es (#3274) This makes the next step for Pyright updating easier, as we can't actually properly represent generics in the IRDL constraint system. Currently, the arith base class helpers work because the generics are all specified by the time the ops are "defined" with the annotation. But my proposed solution of replacing the Annotated with VarConstraints means that we need to define the constraint on a specific type already. My understanding is that this is not a functional change, only requiring some clients of the base classes to update the names that they refer to. Part of #3264 Note stacked PR. --------- Co-authored-by: Alex Rice <alexrice999@hotmail.co.uk>
Using Annotated in the way that we do is not well defined by the Python type system, this fixes the current misuse to get the number of Pylance errors to 0.
The current proposal is to keep both implementations working, and to deprecate the
Annotated
API at some point in the future.