Use known type parameters substitutor after substitutor for fresh variables.
The old logic of substituions had the following order:
- replace known type parameters
- replace type parameters with type variables
- complete inference
- replace type variables with inferred types
According to the updated logic, replacement goes as follows:
- replace type parameters with type variables
- replace known type parameters; if they were variables, this will effectively remove them from inference
- complete inference
- replace remaining type variables with inferred types
Support projection substitution in new type substitutor.
It is needed for correct interaction with old type substitutor.
Old type substitutors can contain mappings constructor -> projection
which couldn't be expressed correctly with existing substitutor API in some cases.
^KT-41386 Fixed
- Merge `duplicatingItemsSameHashCode.kt` and
`duplicatingItemsSameHashCode2.kt` into one test enabled on both
backends, and rename it to
`duplicatingItemsSameHashCodeFewBranches.kt`.
- Rename `duplicatingItemsSameHashCode3.kt` to
`duplicatingItemsSameHashCodeMoreBranches.kt`, and also enable it for
both backends.
- Use JVM_TEMPLATES/JVM_IR_TEMPLATES to check backend-specific behavior:
1) JVM IR does not optimize less than 2 branches by design
2) JVM IR does not generate duplicate branches, also by design
Related to KT-36846.
Before this change, we incorrectly mangled the names of annotation
methods (e.g. `getI-pVg5ArA` instead of `i`) because the isSpecial
condition was false.
It was only used as a superclass in IrInlineReferenceLocator and
LocalDeclarationsLowering. In both cases it's clearer and more optimal
to pass the necessary data via the visitor 'data' variable.
- Add exports for jvm package names used in kotlin.test annotations;
- Export transitively underlying test framework modules
Otherwise "This class does not have a constructor" happens when using
an aliased annotation, e.g. kotlin.test.Test aliased to org.junit.test
KT-41320
A consumer could not resolve the host-specific metadata artifact
of the transitive dependency because the transitive dependency's parent
in the platform dependencies graph did not include the dependency on it
in the variant that is chosen for host-specific source sets metadata:
the dependencies of that variant were empty.
Export the dependencies of the Kotlin/Native target in the host-specific
metadata variant as well.
Issue #KT-41083 Fixed
Pavel Kirpichenkov