It helps to generate properly the annotations for delegates
Also note in test, that annotations in Base class have really weird
text of arguments and also don't have names
Instead of trying to access a missing field `Foo.foo`, call the
synthetic accessor `Foo.access$getFoo$cp` which, as per previous commit,
no longer contains the lateinit assertion
#KT-21862 Fixed
Previously, for a property named `x` in the companion object of a class
named `Foo`, we generated:
- `Foo.access$getX$cp`, consisting of `GETFIELD Foo.x` and lateinit
assertion
- `Foo.Companion.getX`, consisting of `INVOKEVIRTUAL Foo.access$getX$cp`
Now, we generate:
- `Foo.access$getX$cp`, consisting of `GETFIELD Foo.x`
- `Foo.Companion.getX`, consisting of `INVOKEVIRTUAL Foo.access$getX$cp`
and lateinit assertion
The reason is that this way we can avoid generating another accessor and
reuse `Foo.access$getX$cp` in case `isInitialized` is called on a
lateinit property from companion.
For private properties, getX is not generated, but instead the assertion
is generated on each access to the field (which can be improved, see
KT-28331). The same happens for access to non-private properties from
inside the same context where they're declared.
#KT-21862 In Progress
This fixes the most common (and rather annoying) bug in augmented
assignment desugaring with collection element receiver.
Fix is somewhat hackish: introduce an intrinsic for MutableMap.set,
thus bypassing discrepancies in 'get' and 'set' call generation.
Fixing it properly requires design decisions for corner cases where
ad hoc augmented assignment desugaring with collection element receiver
"accidentally" works, producing identical objects and vararg arrays for
arguments of 'get' and 'set'.
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
It's needed to estimate the count of steps for type approximation algorithm.
After the estimated count of steps, we consider such type recursive and this
algorithm returns some default value
#KT-28598 Fixed
KtLightNullabilityAnnotation is specifically designed for old light classes
and includes a bunch of hacks that are applicable for them
So, we have to introduce own hack into it
(see org.jetbrains.kotlin.asJava.classes.KtUltraLightParameter#getTypeForNullability)
that is a bit of hard to support when extending hierarchy
It's necessary because after next changes,
they become different for ultra and old light classes.
The former (ultra) is more correct but it doesn't help when
we need to compare our implementation with reference
One might think that it shouldn't be run because of 'if (declaration
!is KtNamedDeclaration) return' check in the 'check'-overload.
However, for default accessors we pass PSI for property, i.e.
KtProperty (see 'DeclarationCheckers.checkAccessors'), which
obviously passes this check
Note that we can't use `DescriptorToSourceUtils` here, because it's
returns `KtProperty` for default accessor too.
This commits adds specific check for that case, to avoid exception in
KT-28385. Ideal solution would be to either don't launch checkers on
such parameters, or explicitly declare semantic of the
'declaration'-parameter, e.g. to rename it to 'reportOn' (see KT-28403
for discussion)
^KT-28385 Fixed
Previously they were trying to call constructor (incorrectly) for
recursive calls. This is redundant, since this.invoke creates one
automatically.
In addition, support callable references to recursive local suspend
functions.
#KT-24780 Fixed
[JS IR BE] Runtime fixes
* Do not generate external declarations for IR BE
* Move `arrayToString` helper function out of shared JS stdlib
* Fix arrays type check for IR BE
Sometimes, state-machine, generated in inline functions with
crossinline parameter, is transformed, since all usages should be
renamed.
However, this is wrong: in this case, we will have state-machine
inside state-machine.
This fix addresses the issue.
#KT-25893 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)
)
}
```
When trying to estimate if annotation entry might be resolved
to a specified fqName we should track the short name from entry itself
instead of the short name of desired annotation
There's no need to add "values"/"valueOf" methods for them
(see com.intellij.psi.impl.compiled.StubBuildingVisitor#visitMethod that ignores them too)
We already have tests that check enum entries/synthetic methods
are properly resolved in Java:
idea/testData/kotlinAndJavaChecker/javaAgainstKotlin/*Enum*
Dmitry Petrov