"Supports additional builtIn members" setting
is basically adding members to some types
If we analyze them toghether other modules would leak types
that have those members (or don't) into other modules scopes
leading to code that has erroneous highlighting
See KT-17357
#KT-17357 Fixed
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