Skip to content
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

Merged
merged 16 commits into from
Oct 10, 2024

Conversation

superlopuh
Copy link
Member

@superlopuh superlopuh commented Oct 8, 2024

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.

@superlopuh superlopuh added the misc Miscellaneous label Oct 8, 2024
@superlopuh superlopuh requested a review from math-fehr October 8, 2024 22:29
@superlopuh superlopuh self-assigned this Oct 8, 2024
Copy link

Check out this pull request on  ReviewNB

See visual diffs & provide feedback on Jupyter Notebooks.


Powered by ReviewNB

Copy link

codecov bot commented Oct 8, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.99%. Comparing base (964834a) to head (c975ac7).
Report is 6 commits behind head on main.

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.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@alexarice alexarice left a 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
Copy link
Collaborator

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?

Copy link
Member Author

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)
)
Copy link
Collaborator

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What _T?

Copy link
Collaborator

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 ClassVars containing the constraints could be private

Copy link
Member Author

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):
Copy link
Collaborator

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

tests/tblgen_to_py/test.py Outdated Show resolved Hide resolved
xdsl/dialects/builtin.py Outdated Show resolved Hide resolved
ConstraintVar("T"),
]
T: ClassVar[VarConstraint[Attribute]] = VarConstraint(
"T", AnyOf([Sequence, Property, IntegerType(1, signedness=Signedness.SIGNLESS)])
Copy link
Collaborator

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/irdl/constraints.py Outdated Show resolved Hide resolved
ParamAttrConstraint(
IntegerAttr, (AnyAttr(), EqAttrConstraint(IndexType()))
)
IntegerAttr[IndexType].constr(type=IndexTypeConstr)
Copy link
Collaborator

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

Base automatically changed from sasha/misc/pyright-ignores to main October 9, 2024 12:06
@superlopuh superlopuh force-pushed the sasha/irdl/typed-constraints/generic-constraint-var branch from 171cec9 to 33bb59f Compare October 9, 2024 14:55
@superlopuh superlopuh marked this pull request as draft October 9, 2024 14:55
@superlopuh superlopuh changed the base branch from main to sasha/misc/llvm-arith-binop October 9, 2024 14:56
Base automatically changed from sasha/misc/llvm-arith-binop to main October 9, 2024 16:14
@superlopuh superlopuh force-pushed the sasha/irdl/typed-constraints/generic-constraint-var branch from 33bb59f to 947c06a Compare October 9, 2024 22:25
@superlopuh superlopuh force-pushed the sasha/irdl/typed-constraints/generic-constraint-var branch from 83ef4b9 to 1c2d964 Compare October 9, 2024 23:33
@superlopuh superlopuh changed the base branch from main to sasha/misc/arith-split-ops October 9, 2024 23:33
superlopuh added a commit that referenced this pull request Oct 9, 2024
@superlopuh superlopuh changed the title [WIP] misc: use VarConstraint instead of Annotated[ConstraintVar] in operation definitions misc: use VarConstraint instead of Annotated[ConstraintVar] in operation definitions Oct 9, 2024
@superlopuh superlopuh marked this pull request as ready for review October 9, 2024 23:45
Copy link
Collaborator

@math-fehr math-fehr left a 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))
Copy link
Collaborator

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.

Copy link
Member Author

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.

Copy link
Member Author

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

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?

Copy link
Member Author

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

Copy link
Member Author

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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine with me

Copy link
Collaborator

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

Copy link
Member Author

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

superlopuh added a commit that referenced this pull request Oct 10, 2024
…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>
Base automatically changed from sasha/misc/arith-split-ops to main October 10, 2024 10:22
@superlopuh superlopuh merged commit 187eb31 into main Oct 10, 2024
14 checks passed
@superlopuh superlopuh deleted the sasha/irdl/typed-constraints/generic-constraint-var branch October 10, 2024 21:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
misc Miscellaneous
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants