Update diagnostics for new inference.
'Not enough information for parameter' should not be reported for
fake calls and functions with error return type, muted in tests.
Substituting inferred type parameters with single substitutor leads
to incorrect behaviour in cases, when class' type parameters are used in constructor.
As a side effect of two-step substitution, intermediate descriptor is created,
which prevents incorrect substitution. To preserve this side effect, single
resulting substitutor was split into two substitutors: one for substituting fresh
variables and another for substituting inferred variables and known parameters.
^KT-32415 Fixed
Known type parameters appear after inheriting from class with type
parameters. Their substitution matters for inner class constructor,
because without substitution it's parameters will be type checked
against incorrect (original) parameter descriptor with unsubstituted
type parameters.
Skip creation of composite substitutor, if old substitutor is empty.
New substitutors return null in case they don't substitute a type,
but old type substitutors have explicit isEmpty method. Composite
substitutor with empty old substitutor leads to creation
of incorrect descriptor copies.
Consider the following constraint system (from the test example):
Nothing? <: V1
F!! <: V2
Inv<V1> <: S
Inv<V2> <: S
Where V1, V2, S are type variables, and F has nullable upper bound.
Type variable fixation order should be: V2 -> V1 -> S, and the problem
was that previously after fixation of type variable V2 we were trying
to fix S (before V1), so we had the following constraints on S:
Inv<F!!> <: S
Inv<V1> <: S
=> S were fixed to Inv<F!!>
And after this V1 was fixed to F!! which is contradictory as Nothing?
is not a subtype of F!!.
#KT-33033 Fixed
#KT-30297 Fixed
#KT-32168 Fixed
#KT-27722 Fixed (actually, it was fixed with addition of DefNotNullTypes, and now test was added to save this behavior)
#KT-32345 Fixed
Default type of LazySubstitutingClassDescriptor is not lazy. However, most of default types are,
and there is an optimization in KotlinTypeFactory, which uses default type for simple type without
type arguments and/or annotations. LazySubstitutingClassDescriptor's default type creates simple type
with factory, which may therefore cause recursion.
#KT-34029 Fixed
Function return type can't and should not be used during overload resolution of callable references.
Since it can be DeferredType, its substitution in CS caused exception.
The actual problem was introduced in 4f1e85b468, note how `hashCode` is implemented:
```
var currentHashCode = cachedHashCode
if (currentHashCode == 0) return currentHashCode
...
```
It's a silly bug, there should be check `if (currentHashCode != 0) ...` because `0` is used a marker for "uncomputed value".
Now, in the commit 0219b86d06 I added map with `KotlinType` as a key and because of constant `hash` for `KotlinType`, we basically got `List` instead of `Map`, which caused this performance regression
#KT-34063 Fixed
Bug was introduced in b99efb because of lack of tests.
All code in `AbstractTypeCheckerContextForConstraintSystem.extractTypeVariableForSubtype`
related to IN projection looks suspicious and needs further investigation
Consider call `foo(bar())` where bar() returns some type variable `T`;
We had a contract that call `bar` can be completed without completion
of foo (type variables can be inferred from the current context) if `T`
has at least one proper lower constraint (ProperType <: T).
Indeed, new constraints can be added only as upper ones, so there is
no need to grow constraint system.
Unfortunately, we have Exact annotation that is used on return type of
elvis. Now, consider the following situation:
```
fun foo(a: Any) {}
fun bar(e: T): @Exact T
foo(bar("str"))
```
Here, because of Exact annotation, constraint with `Any`-type will be
added as an equal one => our prerequisite that there will be no new
lower constraints is false. `bar("str")` is inferred to Any in OI,
this seems conceptually wrong, but it's another topic of discussion.
In NI we can't just grow constraint system to use outer call because
of another important use-case:
```
fun <T> generic(i: Inv<T>) {}
fun test(a: Inv<*>?, b: Inv<*>) {
generic(a ?: b)
}
```
Common constraint system for these two calls can't be solved
(fundamentally) for this example, only if (a ?: b) and generic(result)
are computed separately.
So, to mitigate initial issue, we'll grow constraint system only if
there is at least one non-proper constraint.
#KT-31969 Fixed
It's enough to have at least one good constraint.
Note that the whole algorithm can be a bit more general:
we could check also Out<T>, In<T> and verify that T has good only
lower constraint or upper constraint, but there are questions for
types like Inv<Out<T>>, where T should have lower and upper constraints
#KT-31514 Fixed
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
Mostly, these optimisations are picked from the old inference.
Also, remove exponential complexity for flexible types in approximation,
note that more correct fix for this would be to introduce new types
that corresponds just to platform types to avoid nullability problems,
but due to complexity it will be done later
#KT-31415 Fixed
Pavel Kirpichenkov