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: add more .constr helpers and constraints #3273

Merged
merged 2 commits into from
Oct 9, 2024

Conversation

superlopuh
Copy link
Member

Pylance errors: 84 -> 74.

Part of #3264

@superlopuh superlopuh added the misc Miscellaneous label Oct 9, 2024
@superlopuh superlopuh self-assigned this Oct 9, 2024
@@ -1559,7 +1562,7 @@ class OptSuccessorOp(IRDLOperation):
# Inference #
################################################################################

_T = TypeVar("_T", bound=Attribute)
_T = TypeVar("_T", bound=Attribute, covariant=True)
Copy link
Member Author

Choose a reason for hiding this comment

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

Necessary for constr definition below, that way BaseAttr[ParamOne[_T]] is a subclass of BaseAttr[ParamOne[Attribute]].

@@ -1436,7 +1457,7 @@ def print(self, printer: Printer) -> None:
f128 = Float128Type()


_MemRefTypeElement = TypeVar("_MemRefTypeElement", bound=Attribute)
_MemRefTypeElement = TypeVar("_MemRefTypeElement", bound=Attribute, covariant=True)
Copy link
Member Author

Choose a reason for hiding this comment

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

this change was made to appease Pyright below, but I'm not really sure that it's kosher... My understanding is that, even though a memref is mutable, and hence a memref type parameter of the memref itself should be covariant, a memref constraint is immutable, so a memref constraint that only accepts cats should be ok to give whenever the client expects a constraint that only accepts animals. Does this seem right? Am I missing something?

Copy link
Collaborator

Choose a reason for hiding this comment

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

If you can store stuff in the memref then this is technically unsound I believe

Copy link
Collaborator

Choose a reason for hiding this comment

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

Actually, I can't even really figure out why this type is generic at all?

Copy link
Member Author

Choose a reason for hiding this comment

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

This is the type not the memref itself. I am now pretty convinced that it's sound, just because all attributes and attribute constraints are immutable, so it makes sense to have their type parameters be covariant. It is not really related to the type of the objects in the IR, as far as the Python type system is concerned.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Looking through the uses of MemRefType, I'm pretty sure this generic argument serves no function whatsoever

Copy link

codecov bot commented Oct 9, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Please upload report for BASE (main@b205332). Learn more about missing BASE report.
Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #3273   +/-   ##
=======================================
  Coverage        ?   89.98%           
=======================================
  Files           ?      444           
  Lines           ?    55615           
  Branches        ?     5350           
=======================================
  Hits            ?    50045           
  Misses          ?     4172           
  Partials        ?     1398           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

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.

🚢

@superlopuh superlopuh merged commit 170ce50 into main Oct 9, 2024
14 checks passed
@superlopuh superlopuh deleted the sasha/misc/all-constr branch October 9, 2024 23:34
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