The names weren't fully explicit in the elaborator, so ambiguity
resolution wasn't able to take advantage of type-directed pruning. Now
they're explicit (but hard-coded, which we should fix later...) so they
can be resolved more easily.
This means we delay ambiguity resolution properly if we hit a depth
error, which means that we can come back to it later and hopefully be
able to resolve it by type on a second attempt.
This is the most likely cause of type checking being too slow, at least
in cases where there's not too much type level computation, so rather
than explore for ages, give up after going under too many ambiguous
names during elaboration.
The depth limit is configurable, with %ambiguity_depth <level>, but it's
very unlikely you'll ever want to do that rather than disambiguating
explicitly.
Do two passes through delayed elaborators (it's impossible to predict
dependency order). Possibly this should keep going as long as it's
making progress? I'll consider that later.
This is a tweak we used in Idris 1: In the end, if there is ambiguity,
and some names generate unification constraints but exactly one doesn't,
take the one that doesn't.
If we have lots of delayed elaborators, and more than one fails, we need
to print the name ambiguity error first since that is the most likely
cause of any other errors.
'case' goes first, because it might help resolve ambiguities. Ideally
we'd keep retrying delayed elaborators until they work, but that's going
to get slow...
- Add support for .lidr files.
- Add new Parse Error for Literate fails.
- Add support for Case Split.
- Add support for Add Clause.
- Add support for Add Lemma.
- Add tests.
This is needed for consistency with the self hosted version (where the
names aren't even available at that point - so it turns out we learn
something from erasability :))
We can work out what it should be since each case is supposed to have
the same type, so we can look ahead to the alternatives. This way, we
don't have to rely on the scrutinee alone to calculate the type of the
case block. (Idris 1 does this too but I've only just encountered the
need for it in Idris 2 now!)
Sorry for the less than informative title :). Lots going on here. It
started as an attempt to fix unification to deal with laziness coercions
in trickier places, but unearthed a couple of tricky and interconnected
issues that are hard to unpick into a single patch. So, this fixes a few
things:
- default hints should only be resolved on the current elaboration (e.g.
nested function definitions, not the outer definition which might not
yet be complete)
- delayed elaborators should be allowed to have nested delayed
elaborators, which means disambiguation is a little bit better
- we should delay elaborating arguments where the type isn't known yet,
because later arguments may resolve the type, and we can use this to
help with disambiguation/laziness coercions
- other bits and pieces arising
Lots of time is taken in finding the definitions to compile, mostly
because the definition itself needs to be decoded from the binary format
in the ttc, but we can at least make the rest of the process fast.
Inlining takes a while - we could improve this later by inlining as we
go, per file, rather than doing it just before compilation.
When we're checking if a definition is a hole and needs updating, when
loading ttc, the names might not fully resolved yet, so don't decode the
definition.
