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
* For types encountered during deserialization, search for a classifier,
not necessarily a class, across module dependencies (i.e. accept type
aliases, returned when actual type alias discriminates an expect
class).
* When the referenced type is a type alias, expand it, so that when
the descriptor is compared to the expansion in other places,
they match.
* Also, when resolving an abbreviation, don't expand the type aliases,
as there are assumptions in the code base that an abbreviation is a
type alias.
Class.getClassLoader returns null for classes loaded by the system class
loader (the one used to start the application). In this case we need to
use ClassLoader.getSystemClassLoader. We already have an extension
`safeClassLoader` specifically for this purpose in reflection.jvm, but
forgot to use it in d59f2bcc80.
#KT-37707 Fixed
Replace it with a dependency on 'descriptors'.
Move the existing marker interface ContractProvider to 'descriptors',
and create a new marker interface DeserializedDescriptor.
Also move version string regex there and rename the class to
RequireKotlinConstants. This allows to get rid of dependency of
'serialization' on 'frontend'.
This has no effect currently because all class files produced by Kotlin
have the bytecode version in the metadata (currently 1.0.3).
However, this change will allow us to stop writing bytecode version to
metadata in Kotlin 1.5. In fact, we could do it while the default here
was INVALID_VERSION too, but then for example compiling with Kotlin 1.3
against binaries of version 1.5 would lead to extraneous "incompatible
bytecode version" errors (because INVALID_VERSION is basically 0, which
is incompatible to 1.0.3+), in addition to the correct "incompatible
metadata version" error.
The reason why we might want to avoid writing bytecode version is the
fact that the initial use case it was added for is already supported by
the metadata version, and the bytecode version error reporting was never
fully implemented. Actually bytecode version was almost unused because
of that.
The new inference uses inferred intersection types normally, unlike the old inference.
However, intersection types in public declarations are approximated to supertype, which
potentially may give a less presice type, then it would be with the OI.
For non-related T1, T2 the NI approximates {T1 & T2} to Any in public declarations,
and if the OI was inferring T1 instead of the intersection type, it may lead to
less precise declaration type and related errors.
The solution is to remember an alternative for an intersection type when present.
Before approximation the alternative replaces the intersection type.
^KT-36249 Fixed
Compiler version changes every build and makes impossible to reuse
caches for heavy tasks such as compiler proguard. We may fix that by
adding version module directly to the final jar.
Writing build number into a public constant field leads to poor gradle
cache reuse between different builds. Public constant value is a part of
public api and its changes affect inputs of dependent modules.
Extracting build number to resource file allows to ignore it from
runtime classpath which fixes same problem for KotlinCompile tasks
Mikhail Zarechenskiy