Its main purpose is code simplification: ImplicitScopeTower::run
contains a lot of local functions that are needed because of
lots of shared state
So, we're moving the state to the Task class instead
NB: This change doesn't change the code of `run`, it will be done
in further commits
The idea is that all tower levels are partitioned into two groups:
- ones that may contain the target name or INVOKE; they're processed as usual
- ones that can't contain the name; they're simply skipped until
the end of resolution process when it's being passed to scope processors
to allow them record necessary lookups
definitelyDoesNotContainName is called too eagerly sometimes and it leads
to obviously redundant lookups
The idea is to put responsibility for calling recordLookup to resolution
itself
The idea is that resolution has an approximate complexity
close to (n + n*m) * 3
Where n is a number of scopes, m is a number of receivers
and 3-constant is used because each of these combinations
runs through 3 processors for functions.
And while call resolver seems to be a hot spot, it should be
useful to decreate the value of n
We set it to 1 now, because otherwise there is examples where
incorporation work too long. We will fix such cases in the future,
but seems like 1 is also good depth delta for incorporation
Introduced new model for resolution result: tree of ResolvedAtoms.
Moved all postprocessing for arguments to front-end module.
Do not create freshDescriptor -- use freshTypeSubstitutor directly.
Removed Candidates for variables+invoke.
Add lazy way for argument analysis -- do not analyze all arguments
if we have subtyping error in first argument, but if we want report
all errors, then all arguments checks will be performed.
Future improvements:
- optimize constraint system usage inside ResolutionCandidate
- improve constraint system API
- improve diagnostic handlers
In front-end we have other ConstraintSystemCompleter and because of this
in dist we have ambiguity(because there all src folders compiles inside
same module.
Type inference completer features:
- type variables depended from result type will be fixed in the end
- type variables with proper constraints will be fixed first
- fixation via groups "accessible" via constraints is supported
TODO:
- stable order via PSI order
- argument constraint should rewrite position if constraint is the
same as upper bound for type parameter
Since now SuccessfulResultCollector do not run computation of
resultingApplicability for error candidate before
getFinalCandidates(). It is very useful because we can do not run
all checks for error candidates if we have not-error candidate.
Denis Zharkov