You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe type checking the return value of a function which is spec-ed to return term() should always pass (the same way as being spec-ed to return any()) as every type is a subtype of term(). (this is of course an under-specification from the side of the user)
This works fine for certain expressions where the subtype function is used, eg:
The tuple on line 48 does not have type term()
The expression [1,2] on line 51 does not have type term()
The record #rec on line 54 is expected to have type term().
I'm willing to fix this, if this is indeed a bug, however I'm not sure if the expect_*_type functions should be extended, or rather do_type_check_expr_in should short-circuit for term() the same way as for any()?
The text was updated successfully, but these errors were encountered:
I believe type checking the return value of a function which is spec-ed to return
term()
should always pass (the same way as being spec-ed to returnany()
) as every type is a subtype ofterm()
. (this is of course an under-specification from the side of the user)This works fine for certain expressions where the
subtype
function is used, eg:However where the check uses the
expect_*_type
family of functions, type checking fails, because these helper functions don't allowterm()
.yields:
I'm willing to fix this, if this is indeed a bug, however I'm not sure if the
expect_*_type
functions should be extended, or ratherdo_type_check_expr_in
should short-circuit forterm()
the same way as forany()
?The text was updated successfully, but these errors were encountered: