The main issue is that we have CombinedModuleInfo in old IDE Resolve,
which essentially merges platfor-modules together with its
dependsOn-parents. It conceals real module structure, which is fine for
practically all clients except for ExpectedActualDeclarationChecker.
In particular, it is nearly impossible to check expect/actual via
ModuleDescriptors, because you'll always get one and the same
'merged'-module descriptor.
So, this commit rewrites IdeaModuleStructureOracle in the following way:
- use ModuleInfos instead of ModuleDescriptor, as they allow more
fine-grained way to work with modules
- use 'unwrapModuleSourceInfo' in seemingly random places in order to
get real, non-merged moduleInfos
- carefully convert them back to ModuleDescriptors, because EADC work
with descriptors
This is still not an ideal solution. In particular, last step is flawed:
conversion back to ModuleDescriptors will always return merged
moduleDescriptor for platform-modules. There's no easy way to fix that
except for removing CombinedModuleInfo altogether, so we leave it as
known issue.
Also, there are some weird changes in testdata (again, because sometimes
we see several modules merged together), but they are mostly confusing
rather than plain incorrect.
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
- Calling suspend functions is allowed
- Presence of suspend function type still makes declaration
unusable unless it belongs to a value parameter as a top-level type
containing less then three parameters
Still, warning should be emitted because they will become unsupported in 1.4
#KT-25683 In Progress
This allows to emulate current compiler behaviour
Introduce CombinedModuleInfo which is a combination of several other modules intended to be analyzed together
Writing a Jigsaw-modular Kotlin program which doesn't require
kotlin.stdlib doesn't make sense because it most likely will fail at
runtime, on access to anything from the standard library. Previously, we
checked that kotlin.stdlib was in the module graph, but that's not
enough, we should also check that the source module requires it.
'-Xallow-kotlin-package' can be used to disable the error.
Add a test checking that an indirect (transitive) dependency is also OK
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
Rename addDeclarations -> registerModuleComponents
Use it to provide SamWithReceiverResolver extensions instead
Post construction on container composition can be achieved
but manually inserting injections where it seems appropriate
is bug prone
This fixes a bug where SamWithReceiverPlugin extension was not registered
for some containers in IDE which led to incorrect highlighting in IDE
Add IDE test for applying SamWithReceiver plugin
#KT-18062 Fixed
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
Denis Zharkov