It's necessary when expect class is actualized via typealias
To support it properly, we need to return AbbriviatedType instead of
SimpleTypeImpl, thus scopeFactory is not enough anymore
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
This fixes an issue in constructing annotation instances with array
class elements. For some reason, behavior of `ClassLoader.loadClass`
differs from `Class.forName` in handling arrays, namely:
* `loadClass("[Ltest.Foo;")` returns null
* `Class.forName("[Ltest.Foo;")` returns class for array of test.Foo
Overall, there doesn't seem to be any way to load an array class with
`CLassLoader.loadClass`.
We pass initialize=false to forName because this is the behavior of
ClassLoader.loadClass: it doesn't perform class initialization (e.g.
<clinit> is not executed).
#KT-31318 Fixed
After the following changes:
* 290aded94f
* 33de71f792
default values of jvmTarget and javaHome started to overwrite properties
set through compileJava in core:descriptors.runtime
The main idea of this refactoring is to separate two usages of
`AnnotationDeserializer.resolveValue`: the one where we load annotation
argument values, and the one where we load constant values of properties
for JS/Native/Common
(`AnnotationAndConstantLoaderImpl.loadPropertyConstant`).
In the latter case, `expectedType` is the type of the property and it
can be a supertype of the actual value (e.g. see `arrayConst` in
compiler/testData/serialization/builtinsSerializer/compileTimeConstants.kt).
But in the former case, we need to check that the value conforms to the
expected type and disregard it if it's not the case, which is possible
if the annotation was recompiled separately.
#KT-28927
Denis Zharkov