We don't print an error message for this, so it's very
confusing if we don't panic - and legacy linker is
going away eventually anyway, so not worth investing in
better error reporting
My concern with the previous wording is that:
- Beginners will be confused by "these are always open"
- Users advanced enough to understand what that actually means won't benefit from seeing it in this warning message!
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
This materially improves performance for programs that are
recursion-heavy (as most Roc programs will likely be).
```
$ hyperfine '/tmp/roc-old check examples/cli/cli-platform/Arg.roc' '/tmp/roc-new check examples/cli/cli-platform/Arg.roc' --warmup 10
Benchmark 1: /tmp/roc-old check examples/cli/cli-platform/Arg.roc
Time (mean ± σ): 53.8 ms ± 1.3 ms [User: 87.3 ms, System: 10.8 ms]
Range (min … max): 52.2 ms … 60.4 ms 51 runs
Benchmark 2: /tmp/roc-new check examples/cli/cli-platform/Arg.roc
Time (mean ± σ): 45.0 ms ± 1.6 ms [User: 59.4 ms, System: 11.3 ms]
Range (min … max): 42.6 ms … 49.8 ms 60 runs
Summary
'/tmp/roc-new check examples/cli/cli-platform/Arg.roc' ran
1.20 ± 0.05 times faster than '/tmp/roc-old check examples/cli/cli-platform/Arg.roc'
```
The time spent in `occurs` during checking for `Arg` drops from 50% to 23%.
MacOS SIGUSR1 is signal 30, not 10 as it is on Linux.
At least on MacOS clang, we need the added headers to the c platform's
host to compile correctly.
Previously we only collected type names that appeared on the surface of
a type during alias analysis, but certain types that need to be named
(i.e. recursive types) may be observed only when we actually convert the IR
to the morphic IR. Make sure we collect those appropriately.
This is a cherry pick of the relevant changes in #4121.
