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 just found out we forgot to handle ! in our type ascriptions. For arguments that wasn't really used (even if allowed), so it was OK, but once we started using the same logic in return type checks that started to cause problems - if you add ! to your return type ascription (which is a good practice from perspective of documentation), the type check gets disabled.
Repro:
from Standard.Base import all
type My_Error
f1 x -> Integer ! My_Error = x
f2 x -> Integer = x
main =
IO.println (f1 42)
IO.println (f2 42)
IO.println (Panic.recover Any (f1 "txt"))
IO.println (Panic.recover Any (f2 "txt"))
Actual behaviour
42
42
txt
(Error: Type error: expected the result of `f2` to be Integer, but got Text.)
Expected behaviour
42
42
(Error: Type error: expected the result of `f1` to be Integer, but got Text.)
(Error: Type error: expected the result of `f2` to be Integer, but got Text.)
The text was updated successfully, but these errors were encountered:
Radosław Waśko reports a new STANDUP for yesterday (2024-06-10):
Progress: Merged 2 PRs, 1 more (Types PoC) to go. Implemented the fix for return type check with complex types and extended test suite to avoid any regressions there; created PR. It should be finished by 2024-06-11.
Next Day: Next day I will be working on the #9486 task. Again get the pending PRs forward. Start work on followup to Snowflake Dialect.
…ing of more complex return types (#10229)
- Fixes#9980
- Adds some tests to ensure types like `|` or `&` (in addition to `!` from the ticket) correctly work in return type check.
- Fixes a weird behaviour where we used to avoid processing type related IR transformations inside of type ascriptions.
- Adds parentheses to type representations if they are more complex: `A | B & C` is unclear as it can either mean `A | (B & C)` or `(A | B) & C` which have different meanings. If we now have an operation with such nesting, the sub expressions are wrapped in parentheses to disambiguate.
I just found out we forgot to handle
!
in our type ascriptions. For arguments that wasn't really used (even if allowed), so it was OK, but once we started using the same logic in return type checks that started to cause problems - if you add!
to your return type ascription (which is a good practice from perspective of documentation), the type check gets disabled.Repro:
Actual behaviour
Expected behaviour
The text was updated successfully, but these errors were encountered: