This was the source of quite a head-scratching error when building the compiler, only solved thanks to @ayazhafiz 's insight. Indeed, compilation of `roc_cli` was failing with an obscure error about linking with `cc` and not being able to find `-ltinfo`. Turns out the fix is as trivial as rearranging nix-shell's `PATH` a little.
I feel like nix-shell will become the default for many users who prefer delegating the necessary setup to the repo's script, and I definitely wish I had known about this when I was starting out.
Is this the right place to mention this or should it be somewhere else in the document?
Just add the shadowing symbol for now. We'll handle checking that a
specialization's type matches the member's type definition in a later
pass, during typechecking.
Just a refactoring PR. This is useful because during canonicalization
we always process type defs first, then value defs. With abilities this
distinction continues to grow; in that case, we have patterns associated
with types that we want to process before patterns from values.
Before we hit mono, we need to make sure the suffixes of numeric
literals are parsed out from the literal string, so that we don't try to
parse something whose type we already know but has the extraneous
suffix.
Co'ed with @tagraves
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
