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.
comparisons.
Having those conversions leads to unnecesary boxing and null checks.
This change does it only for JVM in the optimization lowering. It
is unclear to me if the other backends can get away with something
similar.
The reason for this is that this flag is used right now in 'cli-common'
to workaround the problem that this module is compiled with API version
1.4, but runs with stdlib of version 1.3 (bundled to Gradle). The same
problem would appear with adapted function references, since we use
kotlin/jvm/internal/AdaptedFunctionReference in the bytecode, only
available since 1.4.
The fix is to generate adapted references in this case as subclasses of
the already existing kotlin/jvm/internal/FunctionReference. This can
change behavior in some extreme corner cases (because such references
can now be observed to have reflection capabilities), but it's an -X
argument anyway.
Another option would be to introduce another compiler argument
specifically for this, but it looks like it would only complicate things
without much benefit.
When we inline an anonymous object which captures something such as
crossinline values or reified parameters, we copy and transform its
metadata in `AnonymousObjectTransformer.transformMetadata`. Basically we
read the metadata of the original class, add a minor protobuf extension
and write it to the new class.
This also includes copying the string table. We read the string table
into `JvmNameResolver` (a representation of string table used in
deserialization), then construct a `JvmStringTable` (a representation
used in _serialization_) and then write it back.
There's a few optimizations in the string table representation in JVM
metadata which allow to store less strings and thus take less space. See
`StringTableTypes.Record` in `jvm_metadata.proto` for more information.
One of the optimizations `Record.range` allows to avoid storing the same
record many times in a sequence. For example, if we have N different
strings in the string table but none of them require any operation (such
as substring, char replacement, etc.), then we only store the record
with all default values (no operation, no predefined string, etc.) and
set its `range` to N. Upon reading such optimized record list in
`JvmNameResolver`, we "expand" it back to normal, so that we could index
it quickly and figure out what operation needs to be performed on each
string from the string table.
The problem was that when we expanded this list, we didn't set the range
of the expanded record entry to 1. So each record in
`JvmNameResolver.records` still has its original range. It doesn't cause
any problems most of the time because the range in this expanded list is
almost unused. However, when copying/transforming metadata for anonymous
objects, we mistakenly passed this expanded list with incorrect ranges
to `JvmStringTable`. So the metadata in the copied anonymous object
ended up being incorrect: each record now was present the number of
times equal to its range. Copying such metadata once again led to
another multiplication of the record list size. Multiple copies resulted
in exponential increase in memory consumption and quickly led to OOM.
For the fix, we now take the original, unexpanded list of records when
creating `JvmStringTable` out of `JvmNameResolver` for transformation of
anonymous object metadata.
Note that another possible fix would be to make range for each record in
`JvmNameResolver.records` equal to 1. This is undesirable though, since
then we'd need to copy each `JvmProtoBuf.StringTableTypes.Record`
instance, of which there could be many, and use some memory for no
apparent gain (since ranges in that expanded list are now not used at
all).
#KT-38197 Fixed
This fixes the problem in JVM IR backend which didn't pass bound
receiver value of an adapted function reference to the superclass
(kotlin/jvm/internal/AdaptedFunctionReference), which caused equals to
work incorrectly on such references (see changes in box tests).
Previously, bound adapted function reference was represented as
IrFunctionExpression to an adapter function which calls the callee. The
value of the bound receiver in that case could only be found in the body
of that adapter function. This is not very convenient, so this change
makes psi2ir produce a block of the adapter function + reference to it.
The bound receiver value is then found in the reference. This is
basically similar to what ProvisionalFunctionExpressionLowering is doing
for all function expressions. And since this IR structure is already
supported in FunctionReferenceLowering, the problem in the JVM IR is
fixed without any additional modifications.
However, inliners do not support this IR structure yet, see KT-38535 and
KT-38536.
In general, `InliningContext.findAnonymousTransformationInfo` was not
reliable because it mapped each type to *some* info for that type,
preferring ones with `shouldRegenerate == true` if those exist. Thus, it
returned incorrect results if one type was regenerated multiple times,
e.g. in a nested inlining context or because of a `finally` (which
duplicates anonymous objects). The solution is to avoid a global map and
attach the current transformation info directly to the current inlining
context.
Mikhail Glukhikh