The problem is that now that the local delegated property metadata is in
the $$delegatedProperties array of the containing class, the access to
it from code calling an inline function with a local delegated property
is illegal.
Currently it seems to be a lot of work to support this rather rare case
properly (see the comment in ExpressionCodegen.getVariableMetadataValue)
so we postpone it and return the old behavior of using the anonymous
KProperty subclass for metadata
For tests with local delegated properties, this field is generated in
the full mode, but is not generated in the lite mode because local
variables are not analyzed properly in the lite mode
Instead of generating an anonymous class for each delegated local
variable, store metadatas in the $$delegatedProperties array of the
containing class, as is done for member properties
In CodegenAnnotatingVisitor, store all delegated properties whose
metadata should be generated in each class (identified by ASM Type).
Use the stored information later, both in the $$delegatedProperties
array generation and in the access to it from property's accessor
methods, instead of an heuristical indexOfDelegatedProperty()
When completing calls, update return types for functional descriptors
for lambdas using type inference results.
Add toString to some Call subclasses (for debugging purposes).
Given a lambda result type R_L with constraint R_L <: T,
for each constituent type variable V in T with variance matching
approximation direction for V, consider a dependency edge V -> R
(lambda-result-dependency).
E.g., given a constraint:
R <: Out<V>
where V is approximated down (to sub-type).
After R is fixed, we obtain constraint
Out<T> <: Out<V>
which is incorporated as
T <: V
which is a relevant constraint for V.
1. Value arguments for the resolved call are indexed with resulting
descriptor value parameters (which can be substituted).
2. Simple argument can be a single vararg element if the corresponding
value parameter is a vararg parameter.
3. Resulting descriptor should be approximated to super-type.
This doesn't affect type inference, but the JVM BE expects types with
proper classifiers.
Also do not store type with captured type inside possible types.
It is hack for now, but without it captured types can flow to
resolution and exception will be thrown.
We should never do that, because otherwise we can get unexpected result.
Example for input constraint: C(in String) <: T.
If we run usual subtyping algorithm, then we get 2 constraints:
C(in String) <: T and T <: String.
Of course such system has contradiction.
We prefer denotable types when we solve constraint system.
I.e. if for T we have not equality constraint with captured type we can approximate captured type to denotable type.
This is bad idea, but this is how it works in old inference.
Now we just save old behaviour.
Future plan: fix checks where we get unfinished resolved calls.
- report WRONG_NUMBER_OF_TYPE_ARGUMENTS
- make integral types work again: IntegerValueType is represented as {Int & Byte & Short & Long} in the constraint system
FOR_LOOP_ITERATOR
- temporary variable for for-loop iterator
FOR_LOOP_VARIABLE
- `x` in `for (x in xs)`
FOR_LOOP_IMPLICIT_VARIABLE
- temporary variable for for-loop with destructuring, e.g.:
for ((x, y) in xys)
=>
for (tmp in xys) {
val (x, y) = tmp
}
Knize