Introduce CompositionTypeSubstitution instead of manual composition of
two substitutions.
This change is necessary for the later changes where original substitution
will be able to contain outer type parameters
#KT-11128 In Progress
Because of incomplete infrastructure, introduce a few dirty hacks to make
diagnostic tests analyze the common code via DefaultAnalyzerFacade, and also
add common module sources to analysis of platform-specific modules.
Also do not render 'platform' declarations from platform-specific modules to
the .txt file, since they are very likely to be exact copies of the same
declaration in the common module (see RecursiveDescriptorComparator)
Before creating a MetadataPackageFragment, check that the corresponding
directory (across the classpath) contains at least one .kotlin_metadata file.
Otherwise we're creating packages for every simple name queried during the
resolution and sometimes prefer a (empty) package to the existing class, for
example when the latter class is star-imported
Extract AbstractDeserializedPackageFragmentProvider out of
JvmBuiltInsPackageFragmentProvider and implement it a little bit differently in
MetadataPackageFragmentProvider. The main difference is in how the package
fragment scope is constructed: for built-ins, it's just a single scope that
loads everything from one protobuf message. For metadata, package scope can
consist of many files, some of which store information about classes and others
are similar to package parts on JVM, so a ChainedMemberScope instance is
created.
Introduce a bunch of interfaces/methods to deliver the needed behavior to the
'deserialization' module which is not JVM-specific and does not depend on the
compiler code: MetadataFinderFactory,
PackagePartProvider#findMetadataPackageParts, KotlinMetadataFinder#findMetadata.
Note that these declarations are currently only implemented in the compiler; no
metadata package parts/fragments will be found in IDE or reflection
Compilation of top level functions/properties/typealiases results in a bunch of
different .kotlin_metadata files, so we need to store names of these files to
avoid scanning the file system in the compiler when loading code compiled by
K2MetadataCompiler.
For this, we reuse the PackageTable protobuf message, which is already used for
exactly the same purpose in the JVM back-end
Fixed KT-14939: use expected receiver type when generating receiver code in get/set methods for bound property references.
Otherwise we have VerifyError for bound receiver 'null' of type 'Nothing?', which is mapped to 'java.lang.Void'.
TODO: proper equality comparison for property accessors ('x::prop.getter', 'x::prop.setter').
While it's impossible to declare a property with protected field and public
getter we split these entities
- `_controller` field is used inside coroutines
- `controller` getter is used for accesing controller from noinline lambdas
(also it can be used to obtain controller from continuation by explicit cast)
The main benefit are class-files sizes for them
(not repeating the same declaration for each coroutine)
Also it helped to simplify coroutine codegen code a little
Note that controller/label field become non-volatile (see KT-14636)
#KT-14636 In Progress
Alexey Andreev