Input and output types are crucial for type variable fixation order and
analysis of postponed arguments (callable references, lambdas).
Specifically, if there is non-fixed type variable inside input types of
a callable reference, then we'll postpone resolution for such callable
reference.
Initial example with the expected type `KMutableProperty1<*, F>` caused
problems because input types were computed incorrectly (while there
aren't input types here)
#KT-25431 Fixed
In the desugaring for compound assignment to a collection element,
argument expression 'i' is mapped to value parameters 'iG' and 'iS' of
corresponding 'get' and 'set' operators.
In general, these value parameters can have different indices.
This requires extra machinery in argument generation - that is, to be
able to generate a particular expression argument using an arbitrary
callback. In the vast majority of the cases this callback will just use
the corresponding StatementGenerator to generate IR subtree for the
provided expression. In case of 'get' and 'set' operator calls for an
augmented assignment expression this will map corresponding argument
expressions to pregenerated temporary variables.
Thus, in the following context:
```
class A
operator fun A.get(vararg xs: Int) = 0
operator fun A.set(i: Int, j: Int, v: Int) {}
```
statement `a[1, 2] += 3` will be desugared as (in a really pseudo
Kotlin):
```
{
val tmp_array = a
val tmp_index0 = 1
val tmp_index1 = 2
tmp_array.set(
i = tmp_index0,
j = tmp_index1,
v = tmp_array.get(xs = [tmp_index0, tmp_index1]).plus(3)
)
}
```
In previous commits, renderValueParameter began to calculate its
containing declaration. However, WrappedValueParameterDescriptor
assumes that parent of IrParameter is IrFunction, which is not true
for dispatch receiver parameters. The correct fix would be not to create
WrappedValueParameterDescriptor for dispatch receivers at all and use
WrappedReceiverParameterDescriptor instead. In this fix, I just moved
parameter' containing declaration calculation inside specific option
which is usually false, thus hiding the found problem.
Dmitry Petrov