Mangle invocations of functions with value classes in signature which
override (directly or indirectly) a method declared in Kotlin code.
Otherwise, NoSuchMethodError is being thrown.
^KT-55945: Fixed
The feature was previously enabled unconditionally in K2 which
triggered a bug when an enum has an entry with the same name as itself.
#KT-58897 Fixed
#KT-52774
This commit removes the relevant feature from 1.9 and
makes this feature experimental.
We plan to enable it in some 2.* version (not earlier than 2.1)
Related to KT-54261, KT-36932, KT-49276
#KT-58791 Fixed
^KT-58587 Fixed
Review: https://jetbrains.team/p/kt/reviews/10136
This commit is important in scope of KT-57553. It makes the migration
more smooth.
Other related tests:
- testUninitializedOrReassignedVariables
- testAugmentedAssignmentInInitializer
It acts as a workaround for the case when build tools or dependencies
are compiled with latest 'kotlin-stdlib' version, but at a runtime older
'kotlin-stdlib' is provided, which does not know about new
`EnumEntries`.
^KT-57317 Fixed
Other related tests:
- testGenericJavaProperty
- testFunInterfaceConstructorReference
Meta issue: KT-8575
Review: https://jetbrains.team/p/kt/reviews/9595
UnsupportedSyntheticCallableReferenceChecker only existed for K1,
because we wanted to release the feature for 1.9 and the feature should
have been working for K2 unconditionally. But since, we're postponing
the release until 2.1, we also need to port the checker from K1 to K2
The issue is that during binding fake overrides, the compiler doesn't
differ setters from its properties, so the compiler uses the same
visibility for setter and entire property.
Changing logic at the binding stage can cause some unpredictable consequences so
the fix is to do this differentiation right at the reporting stage
^KT-56662 Fixed
Merge-request: KT-MR-9565
Merged-by: Michail Zarečenskij <Mikhail.Zarechenskiy@jetbrains.com>
The compiler should only report diagnostics for
comparisons over builtins and identity-less types,
other incompatibilities should be reported
via inspections.
It's ok that in `equalityChecksOnIntegerTypes`
instead of `EQUALITY_NOT_APPLICABLE_WARNING` we get
`EQUALITY_NOT_APPLICABLE`, because
`ProperEqualityChecksInBuilderInferenceCalls`
is already active by default.
This change also replaces the notion of a representative superclass
with the least upper bound.
This makes complex types like
intersection/flexible transparent to
RULES1-based compatibility checks.
One way to look at it is to think
that this is an automatic way of handling
type parameters: automatic picking of
"interesting" bounds, and checking them against one another.
Note that `TypeIntersector.intersectTypes`
for `Int` and `T` where `T` is a type parameter
may return both `{Int & T}` or `null`
depending on `T`-s bounds. At the same time,
for type parameters `T` and `K` it will
always return `{T & K}`.
`ConeTypeIntersector.intersectTypes`, on the
other hand, will always return `{Int & T}`
irrespectively of the bounds. Meaning, the two
intersectors differ in corner cases.
`lowerBoundIfFlexible` call in `isLiterallyTypeParameter` is backed by
the `equalityOfFlexibleTypeParameters` test.
^KT-35134 #fixed-in-k2
^KT-22499 #fixed-in-k2
^KT-46383 #fixed-in-k2
Note: here we set sinceVersion = null for this feature.
However, we plan in 1.9.* - 2.0 time frame to solve KT-56377
and to enable this feature in 2.0, the latest in 2.1.
This is required to be able to compile KGP and it's dependencies which
set LV to 1.4 when repo will use LV 1.9. This caused by the change how
enums are compiled (KT-48872).
Ilya Kirillov