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.
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
Use words 'returnArgument' instead of 'resultArgument' when talking
about values, which can be possibly returned from lambda.
Correct 'addSubsystemForArgument' -> 'addSubsystemFromArgument'
The issue here is that OI infers correct types for (k, v) destructing
declaration, while NI infers errors for them. That happens because NI
resolves iterator() on nullable 'm', but rightfully reports it as
unsuccessful, while OI somehow manages to resolve it to success (and
thus getting nice expected type, allowing destructing declaration to be
resolved in a proper types).
Previously, we did approximation of error types to Any?/Nothing in some
contexts (e.g. non-local declarations).
There are several reasons why it is not desired:
- OI doesn't approximate ErrorType
- This behaviour is inconsistent with ourselves (i.e. sometimes we *do*
infer errortype for top-level declaration)
- It causes different digressions from OI in reported diagnostics
This commit turns off error type approximation. It causes large testdata
shift, which is deliberately split into several parts and commited in a
separate commits.
Dmitry Jemerov