Now unsafeResolveToDescriptor is equivalent to resolveToDescriptorIfAny
but throws exception in case no descriptor is found.
Old version of resolveToDescriptor is kept intact but made deprecated.
Some clarifying comments were added
It might be helpful for performance as these methods are called
for each resolution candidate and in the same time they scan
the whole overridden tree of a callable member
This way is more flexible for example for tests, where configuring the
service implementation may be tricky (it's usually done in
KotlinCoreEnvironment in production code)
"Empty" is slightly confusing because although the scope has no declared
symbols, it is not empty: it has a parent scope which can contain
symbols and can have parents as well
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
Replace `takeIf { !expr }` with `takeUnless { expr }`.
Cleanup redundant parethesis as in `listOf((expr))`.
Replace `listOf(expr)` with `expr.let(::listOf)` where the former caused significant indentation change.
Some IDE features relates onto that same descriptors will remain same
between resolve calls
Fix it to be true for TypeAliasConstructorDescriptor's
#KT-16265 fixed
Inject LanguageVersionSettings instead; all information relevant to the
analysis should be now passed via an instance of LanguageVersionSettings
(which should be renamed to a more general name in the future).
This is partially a revert of d499998 and related commits
This makes it possible to drop CompilerConfiguration from
CallCheckerContext, which in turn helps to avoid passing the entire
CompilerConfiguration instance through front-end
Alexander Podkhalyuzin