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
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
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
- clashing JVM signature diagnostics should be reported in stable order
- drop tests for clashes vs package facades
- introduce box test for class named as old package facade
- fix some testData
Alexander Udalov