Previously,
* Equals performs IEEE 754 equality check for floating points and
byte-to-byte checks for other types, including references.
* Ieee754Equals performs IEEE 754 for primitive types
* TotalOrderEquals performs total order equals to all types, including
floating points.
Now it is simplified,
* Equals performs total order checks for all types.
* Ieee754Equals performs IEEE 754 for primitive types.
* (TotalOrderEquals is removed.)
Since we skipped trivial constraint with `Any?` from parameter type of
function `equals`, the compiler thought that there is no proper
constraints (upper bounds do not matter here) and marked resolved
call as a failed one, then diagnostic about missing equals was added
Also, tune `TrivialConstraintTypeInferenceOracle` for `Any?`-like
constraints
#KT-30724 Fixed
Cleanup TypeConstructors & KotlinTypes in VariableFixationFinder
Cleanup TypeConstructors & KotlinTypes in TypeVariableDirectionCalculator
Cleanup KotlinTypes in TypeCheckerContext for ConstraintSystem
Cleanup KotlinTypes in NewCommonSuperTypeCalculator
Cleanup KotlinTypes in TypeApproximator
Cleanup type substitution
Cleanup NewTypeVariable
Cleanup StubType
Cleanup TypeCheckerContext creation, extract common supertype context
Provide TypeSystemInferenceExtensionContext via dependency injection
These tests were added for suspend-conversions, it worked only
with new inference, but implementation was incorrect and had other
bugs, which were fixed in 1ac25259.
Support of suspend-conversions will be addressed later with a different
implementation (#KT-30703)
After cold stream related fixes, we do not generate state machine until
the very last transformation of the lambda. Thus, it is safe to
generate debug metadata for that lambda.
#KT-30694 Fixed
Java constructors can have type parameters of their own:
public class J<X extends Number> {
public <Y extends CharSequence> J() {}
}
When such constructors are called from Kotlin, type parameters for
constructor follow type parameters for class:
fun test() = J<Int, String>() // <X=Int, Y=String>
Descriptor-based representation uses the same type parameters ordering.
Also, use 'withScope' in IrLazyFunction type parameters creation.
Previously, we used a pretty roundabout way to load a MemberScope from a
single file facade represented by KPackageImpl, which involved going
through ModuleDescriptor, PackageFragmentProvider, PackagePartProvider
etc. The only advantage of this approach was that it sort of works
similarly as in the compiler, however mutable state in
RuntimePackagePartProvider and the fact that .kotlin_module files were
required for this to work diminished this advantage.
In this change, we load MemberScope from a KPackageImpl pretty much
directly, by using the existing method
`DeserializedDescriptorResolver.createKotlinPackagePartScope` and
caching the result in the new component PackagePartScopeCache.
#KT-30344 Fixed
Since functionFromStdlibSingleFileFacade.kt was introduced, lazyOf was
also moved to a multifile class, so we're using another function to test
that reflection on a single file package facade from stdlib works
This removes the mandatory dependency of all JVM IR tests on
kotlin-stdlib (ConfigurationKind.ALL in all IR test cases) and speeds up
tests which don't need kotiln-stdlib by about 20%. Another advantage of
this method is that all required dependencies are listed in one file,
are easy to grasp, and changes to the related code generation can be
done independently of the corresponding changes in the actual library,
which may help in bootstrapping the compiler
Ilya Matveev