The -Xskip-metadata-version-check command line argument is supposed to be used
to avoid getting errors only; the side effect that it also caused compiler to
write the pre-release flag to binaries was a mistake and is fixed now
JvmPackagePartProvider should not just blindly load all multifile parts from
all libraries on the classpath, but only those from multifile classes which
shadow (come earlier on the classpath) other classes with the same name.
Otherwise if you have different versions of the same library (which uses
multifile classes) on the classpath, the compiler will see parts from both
versions. If some declaration have moved from one part to another, it's
possible to observe an overload resolution ambiguity error
#KT-15287 Fixed
Gradle can wipe system properties between the build.
If this property is not set, "idea.properties is not found exception"
can be thrown when creating KotlinCoreEnvironment.
LanguageVersion is an enum consisting of the current and all previous versions
only, so with it we won't be able to detect the language version of a future
runtime
Use "-Xno-check-impl" to suppress checking whether the platform declaration
implementation has the "impl" modifier.
Do not check presence of fake overrides from platform class in the impl class,
otherwise there would be a lot of errors about the fact that
equals/hashCode/toString are not marked with the "impl" modifier
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
K2MetadataCompiler is a compiler facade similar to K2JVMCompiler and
K2JSCompiler and it produces .kotlin_metadata files. Each .kotlin_metadata file
contains the binary data which is a serialized BuiltIns protobuf message.
There's no 'kotlinc-***' script yet though, so to run this compiler currently
invoke this:
KOTLIN_COMPILER=org.jetbrains.kotlin.cli.metadata.K2MetadataCompiler kotlinc
Alexander Udalov