Refactor whe way TypecheckingResultsCache is updated:
all mutatiting methods extracted to Update subclass, which is
only available to the updater.
Make TypecheckingState a regular container for (unit) caches.
Make TypecheckingService responsible for managing caches.
Extract TypeModuleOwner and TypeModelHandler classes.
Get rid of QueryResultsCache, merge into TypecheckingResultsCache.
TypeModuleOwner to manage "repository" cache.
Now whether unchecked conversion is allowed is controlled
by ConvertsContext.Options of convertsTo relation.
Introduce 'erased()' term to be used in raw type params.
Drop 'uncheckedConversion' parameter in all macros.
Classifier kind:"raw" is now used only for Recover.
Allow unchecked conversions by default. Forbid for sequences.
Can't properly handle this case now.
To handle this case of no type of initializer in assignment context
need to discern cause of this "no type". If it's because of error --
then can't assign to it any type. If there were no error
(e.g. case of test) -- then type can be inferred from assignment ctx.
Anyway it's not very important corner case, can leave this test relaxed.
Matching on two constraints without an "anchor" (origin)
is essentialy quadratic. On a large root there may be
many typeof/expectType instances and it slows down the
computation considerably.
In with the above flag set to false a conversion of list<T> to list (raw type)
fails, because the latter is represented as list<Object>. (T is any type).
This situation usually arises from queries like coerce(T to concept=ListType).
TypecheckingService and provider component are explicitly dependent
on SRepository.
The repository instance comes from the first opened project, which
is a dirty hack and is temporary until Typechecking Facade API
is fixed to provide appropriate instance.
It was aimed at precluding cascading typechecking failures.
(There was some case with typechecking 'hasBound' after incorrect bind.)
It seems controversial. Typechecking with it is no more predictable
than with free variables left unbound in case of error.
With current tests almost nothing changes after removing it.
These unused in bodies constraints were for tracking certain
cases of incremental dependencies. Now it's handled by minor
algorithm extension introduced in several previous commits.
Fedor Isakov