Otherwise calls to functions which are declared twice (platform and impl) would
result in an error "conflicting overloads" in platform-specific modules
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)
Because PackageViewDescriptor may consist of several package fragments from
different modules (see LazyPackageViewDescriptorImpl#fragments), we now filter
out fragments from irrelevant modules before rendering them into the .txt
E.g. 'impl typealias Foo<A, B> = Bar<A, B>' is allowed; everything else
(variance, changing order of parameters, etc.) is pretty much disallowed.
This is done for simplicity: otherwise matching the platform/impl class scopes
would be not so straightforward
Do not report "unused parameter" for parameters of platform declarations. Do
not allow platform class constructors to have val/var parameters or have an
explicit delegation call to another constructor. Do not allow platform classes
to have 'init' blocks.
Also suppress the "supertype not initialized" error for platform classes: the
supertype should be initialized in the impl class
Also add a new capability for ModuleDescriptor, which is used to obtain the
platform in the multi-platform scenario in tests.
Suppress the following errors for platform functions: "function has no body"
and "nothing to inline". Also do not report redeclaration between platform and
non-platform functions because this is the case when the common +
platform-specific code are analyzed together.
Note that some diagnostics reported in tests are not yet implemented in this
commit, they appear in subsequent commits
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
Do not serialize everything in the same package to the same file (as is done
for built-ins) because this approach is unfriendly to incremental compilation,
which is going to be supported in the future. Instead, similarly to JVM
serialize each class to its own file, and each source file with top-level
callables/typealiases to its own file.
E.g. if a file named test.kt contains a class Foo and some
functions/properties, the output will contain two files: TestKt.kotlin_metadata
and Foo.kotlin_metadata. Each one of this files contains the serialized
BuiltIns message (see builtins.proto)
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
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').
Alexander Udalov