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
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
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
The `@SinceKotlin("X.Y.Z")` annotation now hides a particular declaration from
resolution when the API version specified by the `-api-version` option is
_less_ than X.Y.Z. The comparison is performed as for versions in Maven:
MavenComparableVersion is in fact a copy of
org.apache.maven.artifact.versioning.ComparableVersion.
Also support "!API_VERSION" directive in diagnostic tests
#KT-14298 Fixed
Ensure there's a statically checked dependency on LanguageVersion and
JvmTarget, so that this information is updated automatically once a new
language version or a JVM target is added
Unless the compatibility option "-Xsingle-module" is passed, the compiler will
create two modules instead of one now (see TopDownAnalyzerFacadeForJVM): the
main module contains Kotlin and Java sources and binaries from the previous
compilation of the given module chunk, the dependency module contains all other
Kotlin and Java binaries. This fixes some issues where the compiler couldn't
detect that the used symbol was from another module, and did not forbid some
usages which are only possible inside the module (see KT-10001).
The ideal way to deal with modules here would be to exactly recreate the
project structure, for example as it's done in JvmAnalyzerFacade and usages.
This is postponed until later
#KT-10001 Fixed
#KT-11840 In Progress
Ilya Chernikov