The most interesting part happens in SimpleType.refine, other types
either don't implement refinement at all (they return just 'this',
mainly it's some special types, like ErrorType and such) or implement
it trivially via recursion (those are "composite" types)
SimpleType.refine captures so-called refinement factory, which is essentially
an injected callback which tells how to reconstruct the type with new
(refined) memberScope.
We have to inject callback because we express quite different types with
SimpleTypeImpl, and some of them need different refinement logic.
Another possible implementation approach (more invasive one) would be
to extract those types in separate subtypes of KotlinType and implement
'refine' via overrides.
The most meaningful callbacks are injected from
'AbstractClassDescriptor.defaultType' and from 'KotlinTypeFactory'.
This commit introduces TypeConstructor.refine method.
It's implementation can be roughly split in three parts:
- trivial implementations which just return 'this': mostly, it used for
typeConstructors which can not be refined at all (e.g.
IntegerValueTypeConstructor and other special cases of constructors)
- delegating implementations which call 'refine' recursively for
component typeConstructors -- obviously, they are used in composite
typeConstructors (like IntersectionTypeConstructor)
- finally, the most interesting one is in 'AbstractTypeConstructor'
which returns lightweight wrapper called 'ModuleViewTypeConstructor'.
The idea here is to propagate refinement to supertypes without eagerly
computing them all.
VERY IMPORTANT CAVEAT of TypeConstructor.refine is that call to this
method CAN NOT add new supertypes, so returned supertypes are not
entirely "valid". See the KDoc for TypeConstructor.refine for details
- All refinement-related methods are incapsulated in
ModuleAwareClassDescriptor
- most of classes implement it trivially by retning unchanged scope
- LazyClassDescriptor and DeserializedClassDescriptor have non-trivial
implementations of the refinement-related methods
- General idea is to return new scope which captures refiner and will
later use it to get correct content of itself (currently, refiner is
unused, and will be used for that in later commits)
- In order to not repeat similar work, those new instances of scopes are
cached in ScopeHolderForClass, which is essentially a cache of form
KotlinTypeRefiner -> MemberScope
Unlike previously, this optimisation works on every callee return type.
Tail-calls inside unit functions can be either
INVOKE...
ARETURN
or
INVOKE
POP
GETSTATIC kotlin/Unit.INSTANCE
ARETURN
The first pattern is already covered. The second one is a bit tricky,
since we cannot just assume than the function is tail-call, we also need
to check whether the callee returned COROUTINE_SUSPENDED marker.
Thus, resulting bytecode of function's 'epilogue' look like
DUP
INVOKESTATIC getCOROUTINE_SUSPENDED
IF_ACMPNE LN
ARETURN
LN:
POP
#KT-28938 Fixed
This fixes running IDEA with JPS build.
Gradle only uses compileClasspath configurations
for compilation. Hence the substitution introduced in 5c99243c10
affected only compile tasks (without affecting existing POMs).
However, Intellij import also looks into compileOnly configurations
in order to determine PROVIDED dependencies.
Only dependencies, that are present in both
compileOnly and compileClasspath confgurations,
are considered to have PROVIDED scope.
The substitution was replacing kotlin-reflect with kotlin-reflect-api
in compileClasspath configuration. CompileOnly configurations still resolved
to kotlin-reflect, so a compileOnly dependency to kotlin-reflect
would result in kotlin-reflect-api dependency with COMPILE scope in
IDEA.
This is exactly what happened in 'idea-runner' module, thus breaking
running IDEA from JPS build.
This change fixes the issue by configuring the same substitution
for compileOnly configurations.
Previously `validateTaskProperties` was run with tests
(`test` task depends on `validateTaskProperties` task).
Tests run with `--continue` argument on TeamCity,
so the validation was not failing remote-run builds.
To fix this, make `install` depend on `validateTaskProperties`.
so the REPL remain operational after exception in one of the snippets:
- separately return script class and script instance on evaluation (
because in case of an exception the class is valid, while the instance
is not).
- store both the class and the instance in the history
- handle this data accordingly
move compilation cache setting to the scripting host configuration
The cache implementation can now take into account all external
dependencies that may appear during refinement.
Also change initial refinement location accordingly and rearrange
caching interfaces to make it available in scripting plugin.
Dmitry Savvinov