Previously we assumed that a symbol is accessible if its containing
package is exported by module-info.java. Which was obviously wrong and
could lead to a situation where a symbol would be incorrectly accessible
if a usage module has a dependency on the symbol's module in IDEA
project terms, but does not require it in its module-info.java
#KT-18598 In Progress
In this commit, only IDE tests are added, because we look for module
declarations in the IDE across the whole project, whereas in the
compiler we should do this on the module path only and that requires
separate work (KT-18599) which is done in the following commits.
(The change in Cache.kt is needed so that
JvmModuleAccessibilityChecker.ClassifierUsage, which is an inner class,
would be injected properly.)
#KT-18598 In Progress
#KT-18599 In Progress
"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
