Force constraint system completer to always fix variable with unknown position.
This makes inferred type for in parameters less specific, but OI infers to
subtype in such cases, so NI won't infer to less specific types than before.
Current selection of completion mode for call is not always correct in case of full mode,
and sometimes too conservative in case of partial mode. Updated algorithm checks constraints
wrt position of type variables in return type and in other related constraints.
Full completion happens if proper constraint requirements are satisfied for variables.
Variable with complex dependency on other variable loses its
original constraint position when variable it depends on is fixed.
To prevent that, original input position is saved in incorporation
position.
It's only needed in old FE to avoid clashes when initializing DI
The main idea is gettind rid of intermediate interfaces because
each of them adds another intermediate DefaultImpls call
Call transformer previously ran completion of argument atoms
only for non-error candidates. This led to missing diagnostics,
i.e. from collection literal resolver.
Now arguments of calls resolved to error descriptor are completed,
with exception to not found provideDelegate calls.
provideDelegate's subatoms are not completed after failure, because
it is a part of delegate competion, which does not end with
unresolved provideDelegate.
Completing after provideDelegate failure removes constraint system
from resolved arguments, which breaks resolve for get/setValue.
^KT-33592 Fixed
Vararg parameter in reflection type is interpreted as covariant
array type against array in expected functional type and as
vararg element type otherwise. For instance having function
fun foo(vararg args: Int): Unit { /*...*/ }
reference ::foo can be passed against expected
(Int) -> Unit,
(Int, Int) -> Unit, etc.
In none of such cases type for parameter in foo's reflection type
should be changed to array.
However, against expected type (IntArray) -> Unit args' type
must become IntArray.
^KT-25514 Fixed
Check worked incorrectly in case when argument type and expected type are the
same intersection type, which is possible for local variables without explicit
type declaration.
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
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.
This problem is only relevant when isTypeRefinementEnabled == true (HMPP projects)
Ambiguity accidentally was removed after 471134d
There, for areCallableDescriptorsEquivalent we stopped assuming
as impossible a situation of having identity-different descriptors
in the same containing declaraton that still might be considered equal
So, before 471134d we were comparing
"fun foo(x: String)" with "[substituted] fun foo(x: String)"
and areCallableDescriptorsEquivalent returned false for such case.
Thus, both overrides were left in the resulting set.
After 471134d, those two descriptors
becamed considered as equal thus having a possibility to remove any of them.
The problem is that "areCallableDescriptorsEquivalent" has kind of
unclear contract. Effectively it checks whether two descriptors match
to the same declaration.
But some of the usages expect that it also makes sure that descriptors
have the same substitution (see org.jetbrains.kotlin.resolve.calls.smartcasts.IdentifierInfo.Variable#equals)
So, the straight solution is using original descriptors for the cases
where we need to make sure that descriptors relates to actually different
declarations
^KT-34027 Fixed
The changes introduced 471134d31e are only needed
for the case of HMPP project while for other cases it might break the behavior
a bit like in KT-34027
See org.jetbrains.kotlin.resolve.calls.results.OverloadingConflictResolver#filterOutEquivalentCalls
Before 471134d we were comparing
"fun foo(x: String)" with "[substituted] fun foo(x: String)"
and areCallableDescriptorsEquivalent returned false for such case.
Thus, both overrides were left in the resulting set.
After 471134d, those two descriptors
becamed considered as equal thus having a possibility to remove any of them.
The problem is that "areCallableDescriptorsEquivalent" has kind of
unclear contract. Effectively it checks whether two descriptors match
to the same declaration
But straightforward fixing of this exact call-site (using original descriptors)
doesn't help: behavior might change in a very subtle way (see org.jetbrains.kotlin.spec.checkers.DiagnosticsTestSpecGenerated.NotLinked.Dfa.Pos#test72)
So, the main idea is changing the contract for areCallableDescriptorsEquivalent
only when project is HMPP one.
^KT-34027 In Progress
Pavel Kirpichenkov