This commit addresses the following issues:
* accessors didn't take into account their property's receiver type,
which caused NoSuchMethod due to signature mismatch. Now the property's
receiver type is passed to Fir2Ir translation of accessors.
* property's parent was not class, e.g., kotlin.collections.indices.
Now the symbol table collects WrappedPropertyDescriptorWithContainerSource
besides WrappedFunctionDescriptorWithContainerSource, so that
facade classes for such properties can be generated before codegen.
* accessor's parent was not class. Now the containerSource of
the property descriptor is passed to accessor descriptor.
Library methods such as 'listOf' are resolved
to have the package fragments as their parents,
but JVM expects their containing file classes as parents.
This fix generates those file classes and
uses them as parent replacements for such library methods.
* fixed NoSuchMethod caused by mismatched signatures of the "invoke" method generated for lambda arguments
* added test cases in invoke.kt for KFunction and anonymous functions
* added a transformer to wrap the last expression in the bodies of lambdas with return
Currently FirThisReceiverExpression of instance methods are translated
to references of the class' thisReceiver,
not the method's dispatch receiver,
which causes problems with IrFrameMap::typeOf,
as the class' thisReceiver is not in the typeMap.
This commit translates non-qualified "this" references of
instance methods to references of the methods' dispatch receiver.
Before this commit, we had two methods to do generally the same synthetic thing.
It's an attempt to keep only one of them.
Accessor symbols are generated in Java use-site member scopes,
at this place we know better whether we are in Java class or not.
However, we have to do this at every use-site level, which is relatively slow.
Also we could encounter problems when accessor function is overridden in Kotlin,
and accessor symbol can still contain reference to Java accessor.
Original problem is that lowered ir closures doesn't meet inliner expectations
about captured variable position in inlining method.
E.g.: Call 'foo(valueParam) { capturedParam }' to
inline function 'foo' with declaration
inline fun foo(valueParam: Foo, inlineParamWithCaptured: Bar.() ->) ....
is reorganized through inlining to equivalent call foo(valueParam, capturedParam1, cp2 ...).
But lowered closure for lambda parameter has totally different parameters order:
fun loweredLambda$x(extensionReceiver, captured1, cp2..., valueParam1, vp2...)
So before inlining lowered closure should be transformed to
fun loweredLambda$x(extensionReceiver, valueParam1, vp2..., captured1, cp2..)
#KT-28547 Fixed
Most of these tests used this directive as a way to opt in to a new
language feature, and most of those features are already stable for a
long time, so no opt-in is needed. Some other tests used the directive
to opt out from a language feature, replace those by the `LANGUAGE`
directive. One test used the directive to test behavior that actually
depended on the API version; use `API_VERSION` directive there instead.
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
Local lateinit var differs in behavior from a simple local var,
and logic that relies of 'instanceof Local' checks assuming that all
instances of Local are simple local vars can produce faulty code
(as in KT-23260, where a local lateinit var was not explicitly put on
stack when passed as an argument to an inline function, thus causing
null propagation).
#KT-23260 Fixed Target versions 1.2.50
Before this change, we were computing the visibility of an inherited
private property setter, and ISE at AsmUtil.getVisibilityAccessFlag
happened ("invisible_fake is not a valid visibility in backend")
Denis Zharkov