Every type can have `Eq.isEq` derived for it, as long as
- it does not transitively contain a function
- it does not transitively contain a floating point value
- it does not transitively contain an opaque type that does not support
`Eq`
Prior to this commit, if you had a module structure like
```
| - A.roc
| - Dep
| - B.roc
```
where `B.roc` was defined as
```
interface B exposes [] imports []
```
and `A.roc` was defined as
```
interface A exposes [] imports [Dep.B]
```
The compiler would hang on you. The reason is that even though we expect
`B` to be named `Dep.B` relative to `A`, that would not be enforced.
With this patch, we now enforce such naming schemes - a module must have
the namespaced name it is referenced by. Currently, we determine the
expected namespaced name by looking at how transitive dependencies of the
root module reference the module. In the future, once we have a package
ecosystem and a solid idea of "package roots", we can use the "package
root" to determine how a module should be named.
Closes#4094
Previously we would construct the shapes of unions used in the pattern
tree for exhaustiveness checking using the type of the branch patterns,
rather than the type of the condition variable. Clearly we want to
always use the condition variable, otherwise some branches will be
seen as exhaustive, when they are not!
To do this, we now index into the condition variable while refying the
patterns to build the tree for exhaustiveness checking.
Closes#4068
We have this idea of "rigid optional" fields to annotate record fields
that must necessarily be optional. That avoids the admission of programs
we cannot faithfully compile, like
```
f : {a: Str, b ? U64}
f = {a: "b", b: 1}
```
We want to lose the rigidity restriction when a generalized symbol is
used as at a specialized site; for example it should be possible to call
`f : {x ? Str} -> {}` with both `{}` and `{x : Str}`, neither of which
have a rigidly optional field unless they were to be annotated.
Prior to this commit we would loosen the rigidity restriction upon
specialization of a generalized type at a use site. However, what we
really want to do is apply the loosening during calculation of
generalization. The reason is that otherwise, we must make types that
would be ground (like `{x ? Str} -> {}`) generalized just for the sake
of the optional field annotation. But since the rigidity constraint is
irrelevant after an annotated body has been checked, we can loosen the
rigidity restriction then, which conveniently happens to coincide with
the generalization calculation.
Closes#3955
