This may be more correct in case of complex cross-module inheritance, where
overridability should be detected by structural equality of signatures instead
of referential equality of constructed descriptors (no test added because it's
not so easy to come up with an example)
In subsequent commits, a JVM module will be able to have up to two package
fragments for a given package FQ name. For example, for package "kotlin" in
kotlin-runtime.jar there will be a LazyJavaPackageFragment with binary
(Kotlin+Java) dependencies, and a BuiltInsPackageFragment for built-ins
metadata (which is loaded from kotlin/kotlin.kotlin_builtins)
Use the same approach that is used for creating function type classes
(Function{0,1,...}) + add Cloneable to supertypes of Array and primitive arrays
#KT-5537 Fixed
Use it instead of mapPlatformClass where we only need to check emptiness
because mapPlatformClass requires built-ins and it's not always easy to come up
with the correct instance of built-ins.
In KotlinEvaluationBuilder, use the nullable function
findClassAcrossModuleDependencies instead of mapPlatformClass which uses the
throwing resolveClassByFqName. This is necessary because DefaultBuiltIns, which
are used there, are not always able to find classes mapped by a _Java_ to
Kotlin class map. (The correct solution would be not to use DefaultBuiltIns at
all, instead obtaining the correct instance of built-ins, which are almost
certainly going to be JvmBuiltIns, from the project configuration.)
Currently '()' is used for resolving ambiguity in parsing when annotating function types. This way a decompiled code
will need brackets, but compile code will have annotation without parameters. This commit will allow to make both stub-trees consistent.
Tested in ClsStubBuilderTestGenerated.testAnnotationsOnNullableTypes()
The problem with BasicInterpreter is the following:
it creates BasicValue objects that should be replaced in favor of StrictBasicicValue
See commit message in 25c6ac1 for clarification
#KT-14447 Fixed
Mostly this commit replaces instances of original BasicValue from ASM
with ones of StrictBasicValue having strict equals implementation
Optimization issue was related to non-symmetric 'equals':
- NotNullBasicValue("java/lang/Object").equals(BasicValue("java/lang/Object")) == false
- BasicValue("java/lang/Object").equals(NotNullBasicValue("java/lang/Object")) == true
#KT-14242 Fixed
Equals/hashCode are meaningful for TypeConstructor instances (see
AbstractClassTypeConstructor.java) in contrast to ClassDescriptor where
equality is referential
The main reason currently is to avoid eager construction of
defaultContinuationSupertype long before it's needed, which could fail without
built-ins in the classpath
Alexander Udalov