It's purpose is passing java classes being used during analysis
to incremental compilation to let it track diffs
Potentially it might be done the other way:
incremental compilation could build a separate container to analyze
necessary classes, but it's rather hard to implement now
#KT-17621 In Progress
In kotlin-gradle-plugin, the compiler is invoked with a
K2JVMCompilerArguments instance where both the classpath is set, and the
buildFile is used (containing the same classpath entries in XML).
Previously, the compiler concatenated those two classpaths, which
resulted in duplicated entries, which could slow down compilation. Now,
if buildFile is used, the classpath passed explicitly is ignored
(exactly as, for example, destination ("-d"), which is also stored in
the XML build file).
No test added because there doesn't seem to be any change in
user-visible behavior
Change generic signature of MutableMap.getValue, use 'out @Exact V' and `V1: V` types instead of single `in V`.
Fix affected IR generation tests.
#KT-18789 Fixed
This commit introduces proper handling of recursion in scopes, which
could occur when some of companion object supertypes are members of
that companion owner:
```
class Container {
open class Base
companion object : Base()
}
```
To resolve `Base`, we have to build member scope for `Container`.
In the member scope of `Container`, we see all classifiers from
companion and his supertypes
So, we have to resolve companion objects supertype, which happens to be
`Base` again - therefore, we encounter recursion here.
Previously, we created `ThrowingLexicalScope` for such recursive calls,
but didn't checked for loop explicitly, which lead to a wide variety of
bugs (see https://jetbrains.quip.com/dc5aABhZoaQY and KT-10532).
To report such cyclic declarations properly, we first change
`ThrowingLexicalScope` to `ErrorLexicalScope` -- the main difference is
that latter doesn't throws ISE when someone tries to resolve type in it,
allowing us to report error instead of crashing with exception.
Then, we add additional fake edge in supertypes graph (from
host-class to companion object) which allows us to piggyback on existing
supertypes loops detection mechanism, and report such cycles for user.
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`
Prior to this change, it was rather slow since it would lead
to a ModuleDescriptor::packageFragmentProviderForWholeModuleWithDependencies
computation, that would force the computation of libraries'
dependencies, that actually was the major bottleneck here.
The idea is that we do not need to search through dependencies
of dependencies, but only need contents of one of the modules
direct content.
This commit is made under the assumption that if a module has may see
some runtime parts, than runtime jar should be among its direct
depenencies.
Denis Zharkov