Commit graph

139 commits

Author SHA1 Message Date
Ayaz Hafiz
b406e384fc
Print recursion variables correctly in pretty printer 2023-02-13 17:42:21 -06:00
Joshua Warner
5a6be05ead
implement mono / lowering for tuples 2023-02-07 18:54:50 -08:00
Joshua Warner
303e5bceb3
Fix tuple accessor type printing 2023-01-22 13:22:39 -08:00
Joshua Warner
de828416bf
Initial implementation of tuples in type checking
This leaves in place a bunch of TODOs and likely many bugs - notably, I haven't tested codegen/layout at all here.
2023-01-22 12:40:44 -08:00
Ayaz Hafiz
c3f1646274
Weaken ability members behind let-bindings 2023-01-16 10:49:17 -06:00
Ayaz Hafiz
48049ed956
Weaken tags behind let bindings 2023-01-16 10:49:17 -06:00
Ayaz Hafiz
52c2f3a054
Weaken zero-argument tags in let bindings 2023-01-16 10:49:16 -06:00
Ayaz Hafiz
b8712bcb30
Weaken records in let-bindings
This change also means we must update the interface of `Dict.empty` and
`Set.empty` from

```
Dict.empty : Dict k v
```

to

```
Dict.empty : {} -> Dict k v
```
2023-01-14 15:33:51 +01:00
Ayaz Hafiz
cb1373a3a4
Weaken let-binding calls 2023-01-14 15:33:49 +01:00
Ayaz Hafiz
d27a72de1f
Weaken let sequences under let binding 2023-01-14 15:33:49 +01:00
Ayaz Hafiz
9462f44bb7
Weaken variables bound to when expressions 2023-01-12 10:02:21 -06:00
Ayaz Hafiz
b2cdddbdfb
Weaken lists 2023-01-12 10:02:20 -06:00
Ayaz Hafiz
058644aa96
Implement weakening of variables introduced in branch patterns
Variables introduced in branch patterns should never be generalized in
the new weakening model. This implements that. The strategy is:

- when we have a let-binding that should be weakened, do not introduce
  its bound variables in a new (higher) rank
- instead, introduce them at the current rank, and also solve the
  let-binding at the current rank
- if any of those variables should then be generalized relative to the
  current rank, they will be so when the current rank is popped and
  generalized
2023-01-11 14:28:46 -06:00
Ayaz Hafiz
dc30dbc8a4
Add rank-generalization test 2023-01-10 12:46:34 -06:00
Ayaz
7c61d0d278
Merge pull request #4843 from roc-lang/pattern-as-can
Pattern as can
2023-01-08 19:36:40 -06:00
Folkert
c2ddeb0de0
fix and test as pattern type inference 2023-01-08 16:40:03 +01:00
Ayaz Hafiz
3b0e2429e6
Support printing weak type variables in tests
Unbound type variables that are not at the generalization rank will now
be printed as `w_a` in solve tests.
2023-01-04 16:24:19 -06:00
Folkert
26e5ac85d4
remove argument from the from_str functions 2022-12-29 16:50:19 +01:00
Joshua Warner
174f7d5e4d
Fix bug in unifying records
This was leading us to have an infinitely-recursive type, which eventually causes layout to stack-overflow

Fixes #4739
2022-12-17 11:37:19 -08:00
Ayaz Hafiz
bd06714fd2
Make sure to constrain dbgs with existential correctly 2022-12-14 17:02:29 -06:00
Ayaz Hafiz
cd2b936a59
Ensure that disjoint nested lambda sets force parents to be disjoint
We must be careful to ensure that if unifying nested lambda sets
results in disjoint lambdas, that the parent lambda sets are
ultimately treated disjointly as well.
Consider

```
  v1: {} -[ foo ({} -[ bar Str ]-> {}) ]-> {}
~ v2: {} -[ foo ({} -[ bar U64 ]-> {}) ]-> {}
```

When considering unification of the nested sets

```
  [ bar Str ]
~ [ bar U64 ]
```

we should not unify these sets, even disjointly, because that would
ultimately lead us to unifying

```
v1 ~ v2
=> {} -[ foo ({} -[ bar Str, bar U64 ]-> {}) ] -> {}
```

which is quite wrong - we do not have a lambda `foo` that captures
either `bar captures: Str` or `bar captures: U64`, we have two
different lambdas `foo` that capture different `bars`. The target
unification is

```
v1 ~ v2
=> {} -[ foo ({} -[ bar Str ]-> {}),
         foo ({} -[ bar U64 ]-> {}) ] -> {}
```

Closes #4712
2022-12-12 14:51:18 -06:00
Ayaz Hafiz
f178a86f99
Support pretty-printing can decls in solve tests 2022-12-12 14:50:14 -06:00
Ayaz Hafiz
27dfe974df
Only print lambda ident names in types if they are ambiguous 2022-12-12 14:48:09 -06:00
Ayaz Hafiz
09353733fa
Make sure to register imported variables when importing specializations
Closes #4671
2022-12-05 11:44:28 -06:00
Brendan Hansknecht
28835d5bf3
some bug fixes 2022-12-03 13:17:34 -08:00
Ayaz Hafiz
3605008fce
Update tests to check eq unbound float is resolved to dec 2022-12-01 11:41:42 -06:00
Richard Feldman
b2beeb770e
Merge remote-tracking branch 'origin/main' into https-packages 2022-11-25 19:50:06 -05:00
Ayaz
8c0ff4c839
Merge pull request #4558 from roc-lang/specialization-sets-for-impl-opaques
Support custom abilities for opaques with immaterial lambda sets
2022-11-25 16:42:32 -06:00
Ayaz Hafiz
9dc489c2b0
First pass constraining crash 2022-11-24 14:46:49 -06:00
Richard Feldman
f5cb2d73a1
Merge branch 'precompiled-legacy' into https-packages 2022-11-24 04:29:56 -05:00
Ayaz
3059fd31c9
Merge branch 'main' into specialization-sets-for-impl-opaques
Signed-off-by: Ayaz <20735482+ayazhafiz@users.noreply.github.com>
2022-11-23 17:12:04 -06:00
Ayaz Hafiz
dce4d6c4c7
Force occurs check for introduced types after checking annotated bodies
The current type inference scheme is such that we first introduce the
types for annotation functions, then check their bodies without
additional re-generalization. As part of generalization, we also perform
occurs checks to fix-up recursive tag unions.

However, type annotations can contain type inference variables that are
neither part of the generalization scheme, nor are re-generalized later
on, and in fact end up forming a closure of a recursive type. If we do
not catch and break such closures into recursive types, things go bad
soon after in later stages of the compiler.

To deal with this, re-introduce the values of recursive values after we
check their definitions, forcing an occurs check. This introduction is
benign because we already generalized appropriate type variables anyway.
Though, the introduction is somewhat unnecessary, and I have ideas on
how to make all of this simpler and more performant. That will come in
the future.
2022-11-22 12:58:51 -06:00
Ayaz Hafiz
414a320358
Constrain flex inference variables without re-generalization
When constraining a recursive function like

```
f : _ -> {}
f : \_ -> f {}
```

our first step is to solve the value type of `f` relative to its
annotation. We have to be careful that the inference variable in the
signature of `f` is not generalized until after the body of `f` is
solved. Otherwise, we end up admitting polymorphic recursion.
2022-11-22 10:43:59 -06:00
Ayaz Hafiz
e36618b9e9
Support custom abilities for opaques with immaterial lambda sets
If a specialization of an ability member has a lambda set that is not
reflected in the unspecialized lambda sets of the member's prototype
signature, then the specialization lambda set is deemed to be immaterial
to the specialization lambda set mapping, and we don't need to associate
it with a particular region from the prototype signature.

This can happen when an opaque contains functions that are some specific
than the generalized prototype signature; for example, when we are
defining a custom impl for an opaque with functions.

Addresses a bug found in 8c3158c3e0
2022-11-21 18:03:56 -06:00
Ayaz Hafiz
e1afd964c7
Correct when fixpoint-fixed type variables can be reunified
With fixpoint-fixing, we don't want to re-unify type variables that were
just fixed, because doing so may change their shapes in ways that we
explicitly just set them up not to be changed (as fixpoint-fixing
clobbers type variable contents).

However, this restriction need only apply when we re-unify two type
variables that were both involved in the same fixpoint-fixing cycle. If
we have a type variable T that was involved in fixpoint-fixing, and we
unify it with U that wasn't, we know that the $U \notin \bar{T}$, where
$\bar{T}$ is the recursive closure of T. In these cases, we do want to
permit the usual in-band unification of $T \sim U$.
2022-11-21 15:57:36 -06:00
Richard Feldman
721841fa1f
Provide roc_cache_dir everywhere 2022-11-20 19:53:48 -05:00
Ayaz
1a3119e4c5
Merge pull request #4525 from roc-lang/fix-fixpoints-2
Implement fixpoint-fixing and unconditionally emplace variables into type indices
2022-11-19 17:47:02 -06:00
Ayaz
a74d7e14b7
Merge branch 'main' into i4416
Signed-off-by: Ayaz <20735482+ayazhafiz@users.noreply.github.com>
2022-11-17 09:07:00 -06:00
Ayaz Hafiz
b43078440f
Ensure ability-bound variables are registered in their generalization pool
When we attempt to bind a type argument to an ability in an alias/opaque
instantiation, we create a fresh flex var to represent satisfaction of
the ability, and then unify the type argument with that flex var.
Previously, we did not register this fresh var in the appropriate rank
pool.

Usually this is not a problem; however, our generalization algorithm is
such that we skip adjusting the rank of redundant variables. Redundant
variables are those that are in the same unification tree, but are not
the root of the unification trees.

This means that if such a flex able var becomes the root of a
unification tree with the type argument, and the type argument is itself
generalized, we will have missed generalization of the argument.

The fix is simple - make sure to register the flex able var into the
appropriate rank pool.

Closes #4408
2022-11-16 17:09:47 -06:00
Ayaz Hafiz
972e531431
Check in solve test
Closes #4077
2022-11-16 14:05:52 -06:00
Ayaz Hafiz
9c8a4ec027
Choose hash implementation for ranged number based on default width
Closes #4416
2022-11-16 13:57:03 -06:00
Ayaz Hafiz
ce160f28a2
Chase under aliases during occurs checking
Closes #4368
2022-11-15 16:22:01 -06:00
Brian Carroll
ed048c7c93
Fix more tests 2022-11-12 09:12:28 +00:00
Ayaz Hafiz
3362763e45
Coalesce signature types in value def constraining 2022-11-02 15:05:41 -05:00
Ayaz Hafiz
9854f5f2ac
Print alias's underlying structures if OIOP vars are material 2022-10-31 09:38:22 -05:00
Ayaz Hafiz
debe6332c5
Support OIOP for type aliases 2022-10-31 09:38:21 -05:00
Ayaz Hafiz
cfe7c8e5ef
Warn on the presence of unnecessary wildcards in output positions 2022-10-31 09:38:20 -05:00
Ayaz Hafiz
f3623b1e47
Close extension types extended wiht uninhabited types after their extension 2022-10-31 09:37:40 -05:00
Ayaz Hafiz
d77080529a
Introduce polarity for extension variable printing 2022-10-31 09:37:39 -05:00
Ayaz Hafiz
1f498b52d5
Better name solve test 2022-10-24 14:02:38 -05:00