Since LocalDeclarationsLowering is a BodyLoweringPass, local
functions inside one declaration are handled independently of local
functions in the other declaration. This can lead to name clashes, in
case a local function with the same name and signature is declared in
overloads in the same container, which results in a signature clash
error in JVM IR.
The issue became more common with the introduction of adapted function
references, where psi2ir generates a local adapter-function with a
predefined name, which can easily clash with another reference to the
same target in an overload. This led to a compilation error when
bootstrapping Kotlin with JVM IR, for example in GradleIRBuilder.kt
where there are a lot of references to the same function.
The existing IrGenerationExtension is in the middle of IR construction
and basically requires plugins to work with the (deprecated) descriptors.
Since there are plans to change the IR extension point it makes sense to
introduce a temporary work-around to allow pure IR plugins to be
developed now, which could be ported to a more permanent API later.
- Introduce Ir-based Functional interface factory
- Switch from LazyIr to pure
- Use kotlin library to access raw bytes
- Link dirty files against IC cache and dependencies instead of LazyIr
- Move `DescriptorByIdSignatureFinder` from K/N to common
- Support inline-bodies only MODE
The wrappers for conversions to nullable and non-nullable SAM types are
the same, so differentiating those has no effect other than class name
collisions.
The mental model for inline functions/lambdas is as following:
inline functions have the `inline` keyword before them so it makes sense
for their bodies to be copied at call sites although the compiler might optimize
that if there is no usage of reified type parameters or crossinline value parameters.
But since there is no `inline` keyword around an inline lambda, then
it is logical to think that there will be no copy of it and that it will be just embedded
at the corresponding call site as is.
We can only use IrStrinConcatentation to represent calls to Any?.toString
and toString calls on primitive types. Otherwise, x.toString() and "$x"
are observably different when x is a non-null type with null value
(e.g., an @NotNull value coming from Java).
The fields containing crossinline lambdas should be package-private to
avoid generating synthetic accessors, which break object regeneration.
Note that the inline methods cannot actually be called, as call sites
will attempt to read the captured lambda from a field through a *copy*
of the local containing the object, so these reads will not be inlined,
causing an exception at runtime:
inline fun f(crossinline g: () -> Unit) = object : I {
inline fun h() = g()
// effectively `val tmp = this; return tmp.$g()`:
override fun run() = h()
}
f {}.run() // NoSuchFieldError: $g
This particular example can be fixed by reusing locals for receiver
parameters in IrInlineCodegen, but explicitly assigning `this` to
another variable and calling an inline method on it will break it again.
(This is only applicable to the JVM_IR backend, as the non-IR one fails
to generate `f` at all for some other reason.)
1. Search for increment function in range element type, not in inferred
induction variable type
(which can be inappropriate, e.g., 'Nothing' in case of 'continue').
2. Handle nested loops with shared exit labels
(generated by JVM_IR for KT-37370 case).
KT-37370 KT-37373
Introduce the notion of contagious for overridable declarations.
So, now overriding uncontagious declaration will not lead to becoming a declaration reachable.
By default, all declarations treated as contagious, it's not the most efficient, but it's safest.
In case when we access a declaration through a fake-override declaration,
the original (real) one will not be marked as contagious, so, later,
other overrides will not be processed unconditionally only because
it overrides a reachable declaration.
* unify various checks for whether a suspend function needs a
continuation;
* mark the continuation parameter with an origin (this also allows
correctly computing the offset of the local in codegen -- see the
new test);
* when wrapping `suspend fun main`, use a suspend reference instead of
a synthetic non-suspend lambda (required to correctly implement the
previous point, as previously the continuation parameter was passed
to main() itself correctly only because of very lenient checks in
AddContinuationLowering).
Now that suspend function views are created in
AddContinuationLowering, we can let the
FunctionNVarargBridgeLowering deal with rewriting of large
arity FunctionN/SuspendFunctionN.
values within initializer blocks.
The issue occurs in code like this:
```
class C {
var b = true
init {
b = false // Missing PUTFIELD for this statement
}
}
```
Added a new statement origin for field initialization (at declaration)
instead of relying on `origin == null` in ExpressionCodegen to determine
whether to generate the initializations.
This was unintentionally broken in
d68a1898d0.
2 tests muted due to duplicate variables found by the validator
If memory serves:
- there is a `suspend inline fun` and a callable reference to it
- the suspend function doesn't remove the original function in this
case anymore
- the duplicate `var`'s are inside the function body and the
callable reference state machine body
Roman Artemev