Remove additional logic for comparing files in JavaClassFinderImpl
Drop redundant check for builtins in findClassInJava(FqName)
Drop resolve cache query in LazyJavaClassMemberScope and LazyJavaPackageFragmentScope
IDE:
Rewrite AnalyzerFacade and implementations for JS and JVM to support creating separate analyzers for each module
Introduce ModuleInfo which is an intermediate entity between configuration (tests or idea modules) and ModuleDescriptor
Implement IdeaModuleInfos which represent IDEA modules, sdks and libraries
Add (somewhat thin) test checking their behaviour
Implement getModuleInfo() - utility to obtain IdeaModuleInfo for PsiElement
Drop Project.getLazyResolveSession() - not possible to obtain resolve session for the whole project any more
Adjust JavaResolveExtension accordingly
KotlinSignature Intention/Marker - make sure that analyzed element is cls element (he's not in resolve scope otherwise)
LightClasses:
Create separate package light classes for each module
Java code can only reference light class from the first module among it's dependencies
Duplicate jvm signature is only reported on package declarations inside one module
Injectors:
Receive GlobalSearchScope as paramer for VirtualFileFinder and JavaClassFinder
which allows to narrow analyzer scope
JDR:
Introduce ModuleClassResolver resolves java classes in correct java descriptor resolver (corresponding ModuleDescriptor)
Add test checking that java classes belong to correct module
Debugger:
Provide context to analyze files created by debugger in
Converter:
Postprocessor now needs a context to analyze resulting code in
JetPsiFactory:
Add verification that files created by psi factory are not analyzed without context (that is almost never a good idea)
Other:
Use new API in various tests, utilities, run configuration producers and builtin serializers
Various "TODO: (module refactoring)" which mark the unfinished parts
Change the way modules are configured:
Add dependencies on other modules instead of adding additional package fragment providers
Refactor related code
Drop DependencyKind
Hide common new module creation in CliLightClassGenerationSupport
If a class inherits from another class which captures something (outer class
instance, receiver parameter, local variables, etc.), the constructor of the
former class should contain all the parameters of the super constructor as its
own parameters, so that it could make a proper super call. All such parameters
are now replicated in the derived constructor with kind = SUPER_CALL_PARAM,
except an instance of the outer class (kind = OUTER), which can be taken from
the derived's own OUTER when it has one, to prevent multiple passing of the
same argument.
Previously it worked only when inheriting from inner classes via a special hack
(ConstructorFrameMap).
Also reuse recently introduced ArgumentGenerator to automatically take care of
default and vararg arguments of super constructor
#KT-3581 Fixed
#KT-5342 Fixed
#KT-5343 Fixed
- mutable class, mutable package fragment and their dependencies go to module
'frontend'
- ModuleDescriptorImpl and PackageFragmentDescriptorImpl are moved to the
package "impl" in their module
Deserialization subsystem only need to know about the way to obtain class data, it can construct descriptors itself (no need to call DeserializedClassDescriptor constructor from other modules)
- rename KTopLevelProperty to KTopLevelVariable
- create KTopLevelExtensionProperty, a subclass of KExtensionProperty
- create KTopLevelProperty, a superclass of KTopLevelVariable and
KTopLevelExtensionProperty. (In the future, it will have a container of type
KPackage.)
JVM back-end now generates invocations of these methods instead of
KClass/K*Property/... constructors for two reasons:
1. It occupies less space in the bytecode
2. We can (to some degree) alter the implementation of the factory methods
without changing the ABI compatibility version
Alexander Udalov