`isScript` gets invoked for each call
(see org.jetbrains.kotlin.resolve.calls.CandidateResolver#checkOuterClassMemberIsAccessible)
And currently it may work for O(|top-level-declarations|),
that is rather slow e.g. for native stubs for gtk
#KT-17562 Fixed
This is not needed anymore because we use a special TypeCheckerContext
which correctly matches header class to impl typealias.
Also fix 'platformModule' in areCompatibleClassifiers: it's not b's
module (b is already the expansion of a typealias), but the module of
"other", original 'impl' classifier
Also do not call isHeader/isImpl because the returned declarations are
guaranteed to be isHeader in findCompatibleHeaderForImpl and isImpl in
findCompatibleImplForHeader
Build the compatibility map when looking for header given an impl, in
the same way as it's done for the search of impl given a header. The map
is mostly unused now (only its value at key=Compatible is used), but
will be used in the future to improve the diagnostic messages here
use it from the installed plugin for dependent modules (frontend)
use it from bootstrap in the plugin being built
also drop unused daemon-client from the plugin
This makes it consistent with ant build and allow building idea project
without prior ant dist
Now it's possible to do find usages for other languages when light
elements are used.
Revert efb36f4a49 and revise fix of KT-7983:
Don't consider local and non-local class with same fqn equivalent.
#KT-7983 Fixed
Also, remove kotlin-reflect form container module.
Main goal is get rid of kotlin-reflect.jar from modules what required for minimal compiler.jar which can compile Kotlin only to JS to make it smaller.
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
When resolving a class body for a class without a primary constructor
(e.g., an interface), no checks were performed for redeclarations
in the corresponding class header.
Creating & initializing a lexical scope of an appropriate kind will do it.
Note that since class has no primary constructor, only type parameters
could be redeclared (and that's KT-4960).
To get rid of pointless/confusing implementations in ModuleDescriptor,
PackageViewDescriptor, TypeParameterDescriptor and others.
Note that there are still implementations that do not make sense, for
example in those subclasses of VariableDescriptor which are not also
subclasses of CallableMemberDescriptor (e.g. ValueParameterDescriptor).
Those can be removed by making CallableMemberDescriptor (instead of
CallableDescriptor) inherit from Substitutable. However, that would
require more changes in the compiler because CallableDescriptor is used
rather often in places where in fact only CallableMemberDescriptor
instances can appear.
Explicit return types and casts are required in some places now because
there's no single non-trivial supertype for
ClassifierDescriptorWithTypeParameters and CallableDescriptor.
Previously it was DeclarationDescriptorWithVisibility, now it's both
that and Substitutable<...>
that was moved to the script-runtime, that it a row caused the incompatibility
with old GSK implementations. Now the legacy template resolving related code
is restored, marked obsolete and wrapped for compatibility with the new code.
There's no need to recalculate results if all of the
previous instructions' results remain unchanged.
It's a crucial optimizations because otherwise algorithm
can degrate to O(n * m) [n - instructions number, m - variables number]
even in a linear code like this:
var a_1 = 1
var a_2 = 1
...
var a_m = 1
We perform analysis iteration once, then we repeat it to be sure
that no changes happened and here for each instruction we're
starting to check if recomputed value is the same, that basically
compares maps of all the variables, so it works O(n * m)
After this change on the second iteration we won't recompute new values
as none of predecessor has been changed
Stanislav Erokhin