There is added a new service named `SubstitutingScopeProvider`, that
provides factory that creates captured types and approximator for them.
In OI they are the same as before commit, for NI they are empty, because
that approximation interferes with NI algorithm
That service is injected into function descriptors and property descriptors
and used for creating `SubstitutingScope` with correct services
Also there is changed time when we approximate captured types in NI
(after all call checkers)
#KT-25290 Fixed
Also that commit removes usages of builtins inside
effect system and starts refactoring of functor
composition via composition instead of inheritance.
There are some changes in testdata related to inference of recursive
functions with implicit return types.
After this commit they all are marked as unresolved. It happens because
those functions have DeferredType as return type, and computing this
type produces recursive exception, which provides “typechecker
recursive problem” diagnostic.
Before this commit, function call was completed successfully, because
call completer didn’t computed that type, and computation of DeferredType
were triggered only in `DataFlowAnalyzer.checkType`.
Now, effect system tries to compute that type while wrapping KotlinTypes
into ESTypes, and effect system itself is triggered in in call completer,
so, call completion doesn’t finish and function call is marked as unresolved.
#KT-31364
In 1.3.31 I fixed Java interop for inline function with coroutines
(TL;DR: when we need a state machine, generate two methods: one with
normal name, and the other one with $$forInline suffix, for the inliner
to use, just like inline suspend functions), however, I forgot a case
with inline suspend function with inline suspend function parameter.
In this case, the compiler a generated two functions, as needed, but,
neither of them had a state-machine. This change adds the state-machine
for the method with normal name. Note, that suspend inline functions
with crossinline parameter, which are also supported by the change,
did not cause incorrect behaviour, since until now they were generated
as synthetic.
#KT-31354 Fixed
There is an inconsistency between old and new inference for storing
receivers of resolved calls. In new inference, for captured types,
receiver will be changed and to preserve behavior of the old inference,
we use original one during important checks.
This is more a workaround than a solution and should be revisited.
#KT-31356 Fixed
#KT-29948 Fixed
#KT-31360 Fixed
Dmitriy Novozhilov