Effectively, this commit allows for common module
to see internal content of all expect-modules
The problem is that when computing the member scope for A (see the test)
we're building a special member scope for CommonAbstract viewed from JVM
and it's effectively has a fake override of actual member from Jvm/ExpectBase.
OverridingUtil checks if it's visible in CommonAbstract and finds that it's not
thus creating a fake_invisible fake override
The latter results in A::foo override being marked as INVISIBLE_MEMBER_OVERRIDE
Probably, the fix might be smarter
(passing a requested module to OverridingUtil::createAndBindFakeOverride)
but allowing using internal member seems to be safe & simple
because it's reasonable to assume there's no cyclic dependencies
between expected/actual modules
Otherwise, it results in skipping refinement for JobNode when requested
from JVM module while it's necessary because CompletionHandlerBase's content
depends on the module
matching
This commit makes several changes in testdata:
- compiler multiplatform tests now contain newly introduced diagnostics
about AMBIGIOUTS_ACTUALS
- MultiModuleHighlighitng tests now contain proper reports about
ACTUAL_MISSING:
- ACTUAL_MISSING should be indeed reported in them, because those
tests don't contain dependsOn edges, only usual intermodule
dependencies
- This error wasn't reported here because expect/actual diagnostics in
common module used to be reported by PlatformExpectedAnnotator, which
had a bit flawed logic for deremining common-modules: it checked for
presence of implementing modules. In those tests, common module has no
implementing modules, so Annotator was returning silently
Note that such configurations (common module without implementing
modules) are almost impossible in real-life projects
- After removal of PlatformExpectedAnnotator, we use
ExpectedActualDeclarationChecker in common modules, which launches all
checks properly
- some QuickFixMultuModuleTests now contain proper reports about
ACTUAL_MISSING. This change is also connected with
PlatformExpectedAnnotator, but now for different reason:
- QuickFixMultiModuleTest used to check for errors in file by running
'analyzeWithAllCompilerChecks' and inspecting returned BindingTrace.
For common modules, there were no diagnostics about expect/actuals in
that trace, because there were no ExpectedActualDeclarationChecker
(and PlatformExpectedAnnotator was reporting diagnostics in ad hoc
trace).
- Again, now we inject EADC in common modules properly, so we see
those errors in trace and report them in test
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
Nikita Bobko