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
ExpressionsOfTypeProcessor searches for all occurence of expression
with given type. It start from usages of the class, searches for sub-classes,
declarations that return those classes, usages of these declarations,
and so on.
During this search, find usages for all operators that return the
subject type is executed as sub-queries. Full search for such queries
can't give addition types. And it also shouldn't give additional scopes
for search, because same scopes should be located by operands. In other
words, if sub-query can spot the scope of usage starting from the same
type, the original query should also process same scope.
#KT-18566 Fixed
It's a superficial fix: the bug is actually caused by
uninitialized companion instance reference in
Kotlin2JvmCompilerArgumentsHolder class
#KT-18505 Fixed
- Move the following from 'deserialization' to 'descriptors':
NotFoundClasses.kt
AdditionalClassPartsProvider.kt
ClassDescriptorFactory.kt
PlatformDependentDeclarationFilter.kt
findClassInModule.kt
- Move the following form 'descriptors' to 'deserialization':
BuiltInSerializerProtocol.kt
builtInsPackageFragmentProvider.kt
- Extract a marker interface from BuiltInsPackageFragment and move its
implementation to 'deserialization'
- Change the type of parameters in PlatformDependentDeclarationFilter
and AdditionalClassPartsProvider to ClassDescriptor
This will help in getting rid of the circular dependency of
'descriptors' <-> 'deserialization'
"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
Backend: If kotlin class extends kotlin.collection.List
write it as it's super interface (light class mode only)
IDE: Provide wrapper classes to java resolve
that try to emulate backend behaviour
For example if kotlin class implements kotlin.collections.Map,
we provide a superinterface that has abstract 'getEntries' method
and 'entrySet' method that is considered default.
In reality all those methods are generated in the class itself.
In IDE supporting this case without hacks is not feasible performance-wise
since kotlin.collection.* may not be an immediate supertype and we need
to compute all supertypes just to calculate own methods of the class
Dmitry Jemerov