There was an issue that `KotlinType.equals` called in `KotlinTypeFactory.flexibleType`
and `RawType` constructor produced endless recursion of types that wasn't
computed yet
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'.
`RuntimeTypeMapper.mapSignature` threw exception because the descriptor
for `clone` was created manually in CloneableClassScope and therefore it
didn't have a JVM signature as in deserialized descriptors, and wasn't
recognized as a Java method either.
#KT-22923 Fixed
This commit introduces the ability to register a PlatformExtensionClashResolver
in a container. Each PlatformExtensionClashResolver has a corresponding
PlatformSpecificExtensions.
If, during container composition, several instances of
PlatformSpecificExtensions were registred, instead of throwing
InvalidCardinalityException, corresponding PlatformExtensionClashResolver
will be asked to resolve clash.
This allows to make injection more composable and less coupled across
different contributors of service, providing a basis for such motivating
cases as composing containers with both JS and JVM services (for analysis
of multiplatform modules).
Previously, that would be impossible:
a) JS would inject default instances for some services which would clash
with non-default JVM services (like SyntheticScopes)
b) Also, there are a very few services for which *both* platforms provide
non-default implementations, so they should be merged manually on
case-by-case basis (e.g., IdentifierChecker)
A synthetic property descriptor created for `B.value` (see the added
test) should not be equal to the normal descriptor created by the fake
override construction algorithm. Otherwise we can't reach this synthetic
non-abstract descriptor when building bridges in `C`, which results in
exception.
#KT-31367 Fixed
There is added a new service named `SubstitutingScopeProvider`, that
provides factory that creates captured types and approximator for them.
In OI they are the same as before commit, for NI they are empty, because
that approximation interferes with NI algorithm
That service is injected into function descriptors and property descriptors
and used for creating `SubstitutingScope` with correct services
Also there is changed time when we approximate captured types in NI
(after all call checkers)
#KT-25290 Fixed
In case Java enum has an abstract member, it has the ACC_ABSTRACT flag
set in the bytecode. However, we should still load it with final
modality to be consistent with Kotlin enums which are always considered
final
#KT-23426 Fixed
In TopDownAnalyzerFacadeForJVM, we now always use the "load built-ins
from module dependencies" behavior that was previously only enabled with
the dedicated CLI argument -Xload-builtins-from-dependencies. However,
sometimes we compile code without kotlin-stdlib in the classpath, and we
don't want everything to crash because some standard type like
kotlin.Unit hasn't been found.
To mitigate this, we add another module at the end of the dependencies
list, namely a "fallback built-ins" module. This module loads all
built-in declarations from the compiler's class loader, as was done by
default previously. This prevents the compiler from crashing if any
built-in declaration is not found, but compiling the code against
built-ins found in the compiler is still discouraged, so we report an
error if anything is resolved to a declaration from this module, via a
new checker MissingBuiltInDeclarationChecker.
Also introduce a new CLI argument -Xsuppress-missing-builtins-error
specifically to suppress this error and to allow compiling code against
compiler's own built-ins.
#KT-19227 Fixed
#KT-28198 Fixed
Java type enhancement is performed by a special scope kind
Java FIR dump was added for multiplatform tests to look at enhancements
Overrides, J2K mapping, special cases does not work yet
Related to KT-29937
Vladimir Dolzhenko