We don't have true flexible types in the IR, but we approximate it with
internal type annotations, such as FlexibleNullability,
FlexibleMutability, RawType. These annotations are then handled
specially in JvmIrTypeSystemContext, which can construct a fake flexible
type so that type checker on IR types would behave exactly as on
frontend types.
As shown in KT-63441, one instance of flexible types where flexibility
was lost during conversion to IR is Java array/vararg types. It's
necessary to support it so that IR fake overrides could be constructed
correctly, because IR fake override checker requires parameter types to
be equal. So this change introduces another internal type annotation,
FlexibleArrayElementVariance, which is only applicable to types with
classifier kotlin/Array, and which signifies that the annotated type
`Array<X>` should rather be seen as `Array<X>..Array<out X>`.
#KT-63441 Fixed
#KT-63446 Fixed
This call to isAbstractMethodOfAny was in Fir2IrLazyClass since its
inception in 0622be14a5, and there's no explanation why this was
necessary. Removing it does not seem to break anything, but fixes the
case when IrFakeOverrideRebuilder is enabled and when Java base class
declares an abstract equals/hashCode/toString which is not overridden in
the Kotlin subclass.
#KT-63443 Fixed
To make it possible to change nullability of IrCapturedType and change
its annotations, which is happening when determining overridability of
functions via IR.
#KT-63437 Fixed
In case there are Java sources in the module, K2 creates two instances
of `FirModuleDescriptor` with the same name: one for Kotlin sources, one
for Java sources. When building fake overrides in IR, it's important to
understand that those are the same module. Currently it's done by
comparing the names, but in the future it may be improved in KT-62534.
The changed test was in fact unrelated to KT-61805, and the problem
there was rather that no fake override was created for internal property
`schemeState` in `InspectionProfileModifiableModel`.
`FakeOverrideBuilder.provideFakeOverrides` recursively changes overrides
for all superclasses in the hierarchy, including lazy IR, which is a lot
of extra work.
Also it leads to some tests failing in the IR fake override builder mode
because it changes correct fake overrides of Java classes to incorrect
ones. Those tests are unmuted but it doesn't mean they are fixed -- most
likely we'll generate fake overrides via IR for lazy IR too, at which
point they'll start to fail again.
Disabling of this language feature (see KT-57570) was not supported in
the (default) light tree mode, and after this change it will not be
supported in the PSI mode as well. This makes the behavior more
consistent and allows us to remove the directive
IGNORE_BACKEND_K2_LIGHT_TREE in the future (KT-56757).
When building the original for a substitution override for a synthetic
property, use the initial setter as fallback when unsubstituting it
returns null. This can happen when a generic class overrides the getter
of a synthetic property of a non-generic class. Then the setter is never
substituted, therefore there is nothing to unsubstitute.
^KT-57168 Fixed
If a synthetic prop clashes with a real property (e.g. @JvmField
property from parent Kotlin class), don't generate fake override for the
synthetic property. This fixes a CONFLICTING_INHERITED_JVM_DECLARATIONS
error in a mixed hierarchy.
^KT-56538 Fixed
useCorrectedNullabilityForTypeParameters = true only might lead
to something becomes a DNN when otherwise it wasn't.
It seems safe to use it here, since if compiler has generated DNN, then
it's OK to assume that it checked necessary conditions, and it's likely
that it had useCorrectedNullabilityForTypeParameters = true as well, there.
Anyway, it looks saner than having an exception here.
Also, we assume here that metadata leading to exception might only be generated
with ProhibitUsingNullableTypeParameterAgainstNotNullAnnotated LF
(at least, we don't have contradicting evidences),
thus it's mostly a preparations in case we decide to enable
ProhibitUsingNullableTypeParameterAgainstNotNullAnnotated in 1.9.
^KT-55357 Fixed
^KT-55388 Related
^KT-36770 Related
Previously, it worked by default because ProhibitUsingNullableTypeParameterAgainstNotNullAnnotated
was enabled by default since 1.8, but we have to disable it because of KT-55357
Turning off the fix by default is not a breaking change per se, because
1.8 has not yet been released.
^KT-55357 Related
^KT-36770 Related
^KT-53041 Open
* Change 1.6 to 1.7 constants
* Fix SAFE_CALL_WILL_CHANGE_NULLABILITY for testData
* Change EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_WARNING to EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_ERROR
* Change NON_EXHAUSTIVE_WHEN_STATEMENT to NO_ELSE_IN_WHEN
* Fix testData for SafeCallsAreAlwaysNullable
* Change T -> T & Any in test dumps
* Change INVALID_CHARACTERS_NATIVE_WARNING -> INVALID_CHARACTERS_NATIVE_ERROR
* TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_WARNING -> TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_ERROR
We are going to deprecate `WITH_RUNTIME` directive. The main reason
behind this change is that `WITH_STDLIB` directive better describes
its meaning, specifically it will add kotlin stdlib to test's classpath.
Mikhail Glukhikh