-
Notifications
You must be signed in to change notification settings - Fork 49
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
Fix typing of cast_
builtin in ITIR type inference
#1182
Conversation
@havogt Please also take a quick look at the implication of making |
# 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"] |
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 don't understand this change. It seems the test works without.
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.
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_": |
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.
The alternative would be to bring type of type into the typesystem, right?
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.
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.
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.
A few more questions
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.
Looks good!
The typing inference rule for
cast_
was not correctly implemented when the builtin was introduced. This PR fixes that by makingcast_
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).