This allows to emulate current compiler behaviour
Introduce CombinedModuleInfo which is a combination of several other modules intended to be analyzed together
Now ExpectActualDeclarationChecker in IDE context
uses common module descriptors for relevant checks.
Compiler still uses own module instead (see comment in checker)
So #KT-21771 Fixed
This function is now used instead of allImplementingCompatibleModules,
thus allowing it to be deleted together with allImplementingModules
So #KT-17369 Fixed
So #KT-17374 Fixed
May fix also some other MPP issues
Note that the quick fix to implement header class works incorrectly when
that class has nested classes at the moment; this should be fixed
separately
#KT-15494 Fixed
#KT-18573 Fixed
Try to report most of the errors on the actual members of the impl
class. In many cases, there's a 1:1 mapping of header to impl class
members, so the error "some members are not implemented" on the class
declaration itself is redundant. Exceptions include functions/properties
from supertypes (there may be no other place to report a signature
mismatch error in this case), functions/properties not marked with
'impl' (the checker is only run for declarations explicitly marked with
'impl') and default constructors (the checker is not run for them)
#KT-18447 Fixed
Try to report most mismatch errors on the 'impl' declaration. Only
report a mismatch error on the 'header' declaration if no error would be
otherwise reported on any 'impl' declaration in the compilation unit.
Also render declaration kind in the message
#KT-18447 In Progress
Currently kotlin-stdlib-common doesn't have serialized built-ins inside,
so in a multiplatform project, it was possible that either JVM or JS
built-ins (depending on the order of entries in the project
configuration) were going to be used for the analysis of a common module
depending on kotlin-stdlib-common. This resulted, for example, in
additional built-in member calls (e.g. "List.stream()") being unresolved
in JVM modules when they used the List instance coming from the common
module (see the added test)
Instead of reusing the same AnalyzerFacade that is used for resolution
of a module to resolve its dependencies, analyze each dependency
module/library with a facade depending on its target platform. Introduce
and use CommonLibraryDetectionUtil in addition to
KotlinJavaScriptLibraryDetectionUtil, to detect common libraries (with
.kotlin_metadata files).
Note that before multi-platform projects, this was not needed because
there were only two platforms (JVM and JS), and JVM module had only JVM
modules/libraries as dependencies, JS module had only JS
modules/libraries as dependencies. Now, for example, a JVM module can
have a common module/library as a dependency, and it would be incorrect
to analyze that dependency with JvmAnalyzerFacade because that facade
does not know anything about .kotlin_metadata files.
The changes in Dsl.kt and KotlinCacheServiceImpl.kt are needed because
PsiElement.getJavaDescriptorResolver, called from some IDE code, started
to fail on a common module, because the container for a common module
does not have the JavaDescriptorResolver
Pavel V. Talanov