It leads to undesired behaviour
such as returning library source when only binaries are queried
It is redundant since js libraries do not include kotlin source files
(real binary format is used for this purpose for along time now)
This is faster than going through FilenameIndex which would call
GlobalSearchScope.accept for all "module-info.java" files in the
project, and there can be many of those.
Also see https://github.com/JetBrains/intellij-community/pull/670
In Gradle, JavaPsiFacade finds Kotlin compiled files as KtFile instances
and tries to obtain classes from them.
And while it returns an empty array anyway, it starts building
unnecessary stub when calling `isScript`
Effectively it leads to all stubs being built for any once used package
The idea is that they only were used for FILE_TO_PACKAGE_FRAGMENT
that is mostly read in backend and rarely in the IDE, so we can replace
its usages with searching through related package-fragments
It should help with actual loading of all the stubs for all declarations
in the package on every access when it's implemented through
`getDeclarations()`
The problem is that they might indirectly retain a reference to an
obsolete ResolverForProject (it becomes outdated after out of block
modification).
The best solution would be to avoid preserving jvm-related diagnostics
(that are only used once to report them when highlighting, and exactly
they retains an obsolete resolve session)
But it seems that this may lead to a deep light-classes refactoring and
the temporary fix is storing diagnostics themselves in a CachedValue
bound to out of block modification tracker. There're no guarantees that
this would help, since CachedValue anyway is based on soft-reference
that is not the first thing GC collects
Original issue here - structure of VfsEvents,
when directory gets deleted, we receive only VFileDeleteEvent
for directory, but not it's content, so we should invalidate
all modules in which sources this directory located, and all
modules that located in such directory
Second problem - When VirtualFile was deleted it is impossible to
get ModuleInfo for it using getModuleInfoByVirtualFile
Third problem - stale references in cache, due cycle dependency
#KT-20987 Fixed
Single execution path to report missing package fragment problems
Split failures on PluginDeclarationProviderFactory site by
known reasons to improve exception analysis
Mikhail Glukhikh