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

Fix typing of cast_ builtin in ITIR type inference #1182

Merged
merged 6 commits into from
Feb 23, 2023

Conversation

tehrengruber
Copy link
Contributor

The typing inference rule for cast_ was not correctly implemented when the builtin was introduced. This PR fixes that by making cast_ part of the grammar (similar to how this is handled in the frontend). This restriction could be lifted in the future (e.g. by introducting a type of a type).

@tehrengruber
Copy link
Contributor Author

@havogt Please also take a quick look at the implication of making cast_ part of the grammar (see the test for an example).

Comment on lines 351 to 364
# Note: We need to exec the stencil here since the dtype must be a type literal.
locals = {}
exec(
textwrap.dedent(
f"""
@fundef
def sten_cast(value):
return cast_(deref(value), {dtype})
"""
).strip(),
globals(),
locals,
)
sten_cast = locals["sten_cast"]
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't understand this change. It seems the test works without.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Mh, previously the type checking tests failed and I (apparently) misinterpreted the reason to be located here. I works now, so I removed this change.

@@ -477,6 +477,39 @@ def visit_FunCall(
)
constraints.add((tup, val))
return Val(kind=kind, dtype=elem, size=size)
if node.fun.id == "cast_":
Copy link
Contributor

Choose a reason for hiding this comment

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

The alternative would be to bring type of type into the typesystem, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I discussed the idea with @egparedes a while ago (in the context of the frontend). I believe the conclusion was to wait until we really need this.

Copy link
Contributor

@havogt havogt left a comment

Choose a reason for hiding this comment

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

A few more questions

@tehrengruber tehrengruber requested review from havogt and removed request for egparedes February 23, 2023 13:17
Copy link
Contributor

@havogt havogt left a comment

Choose a reason for hiding this comment

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

Looks good!

@tehrengruber tehrengruber merged commit 7908f27 into GridTools:main Feb 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants