We made it because of non-stable name resolution when project is multi platform. For such projects in platform module we have two classifiers with the same name, but impl class or type alias should win!
Metadata version is 1.1.2 since the start of Kotlin 1.1 EAP. Because the
pre-release flag was not written to class files compiled with 1.1 EAP, there's
no other way to figure out that they're pre-release except than to look at the
metadata version. This assumes that the version will be advanced to 1.1.3 once
Kotlin 1.1 is released
Catch all exceptions when deserializing metadata with an incompatible version
to prevent the compiler from failing on discovering incompatible classes on the
classpath. Note that this is not the perfect solution: any invariant may be
broken in the incompatible metadata and it may result in a later exception
Similarly to pre-release classes, load metadata for the class anyway and allow
the resolution to select it as the result and prohibit its usage in the end
with the special diagnostic reported in MissingDependencyClassChecker
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
Provide a command-line option to load built-ins from the module and its
dependencies instead of looking for them in kotlin-compiler.jar; built-ins must
be found this way, or an error will be reported (or, most likely at this
moment, an exception will be thrown).
Note that this does not affect whether built-ins (loaded from one place or the
other) are added to the _dependencies_ of the module, this is controlled by
another option. The option added in this commit only makes the KotlinBuiltIns
instance which is used via ModuleDescriptor throughout the compiler front-end
(and also injected in a bunch of places) a sort of "helper" which always goes
to that same module to find descriptors for built-in classes
Introduce a new method KotlinClassFinder#findBuiltInsData, which is only
implemented correctly in the JvmCliVirtualFileFinder because it's only used in
the compiler code at the moment.
Introduce JvmBuiltInsPackageFragmentProvider, the purpose of which is to look
for .kotlin_builtins files in the classpath and provide definitions of
built-ins from those files.
Also exclude script.runtime from compilation because, as other excluded
modules, it has no dependency on the stdlib and is no longer compilable from
the IDE now, because it cannot resolve built-ins from anywhere
In subsequent commits, a JVM module will be able to have up to two package
fragments for a given package FQ name. For example, for package "kotlin" in
kotlin-runtime.jar there will be a LazyJavaPackageFragment with binary
(Kotlin+Java) dependencies, and a BuiltInsPackageFragment for built-ins
metadata (which is loaded from kotlin/kotlin.kotlin_builtins)
Use the same approach that is used for creating function type classes
(Function{0,1,...}) + add Cloneable to supertypes of Array and primitive arrays
#KT-5537 Fixed
Use it instead of mapPlatformClass where we only need to check emptiness
because mapPlatformClass requires built-ins and it's not always easy to come up
with the correct instance of built-ins.
In KotlinEvaluationBuilder, use the nullable function
findClassAcrossModuleDependencies instead of mapPlatformClass which uses the
throwing resolveClassByFqName. This is necessary because DefaultBuiltIns, which
are used there, are not always able to find classes mapped by a _Java_ to
Kotlin class map. (The correct solution would be not to use DefaultBuiltIns at
all, instead obtaining the correct instance of built-ins, which are almost
certainly going to be JvmBuiltIns, from the project configuration.)
Alexander Udalov