Unify type alias "real variables"

Turns out that we can't always assume that a successful unification of
type alias type variables means that those aliases had the same real
type from the start. Because type variables may contain unbound type
variables and grow during their unification (for example,
`[InvalidNumStr]a ~ [ListWasEmpty]b` unify to give `[InvalidNumStr,
ListWasEmpty]`), the real type may grow as well.

For this reason, continue to explicitly unify alias real types for now.
We can get away with not having to do so when the type variable
unification causes no changes to the unification tree at all, but we
don't have a great way to detect that right now (maybe snapshots?)

Closes #2583
This commit is contained in:
Ayaz Hafiz 2022-04-05 11:21:52 -04:00
parent 19c02aa087
commit 163c6b39d6
No known key found for this signature in database
GPG key ID: 0E2A37416A25EF58
6 changed files with 86 additions and 8 deletions

View file

@ -1273,6 +1273,15 @@ fn issue_2725_alias_polymorphic_lambda() {
)
}
#[mono_test]
fn issue_2583_specialize_errors_behind_unified_branches() {
indoc!(
r#"
if True then List.first [] else Str.toI64 ""
"#
)
}
// #[ignore]
// #[mono_test]
// fn static_str_closure() {