Using files turned to be a bad idea, because people often
use the same name for files with expects and with corresponding actuals.
This commits disambiguiates ambiguous message for
AMBIGUOUS_ACTUALS/AMBGIUOUS_EXPECTS diagnostics by using modules instead
of files
^KT-32582 Fixed
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
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
Dmitry Savvinov