During converting library annotations to FIR nodes
and building required scopes inside, lazyResolveToPhase may be called.
For such cases it's okay to skip the lazy resolve contract checks as
those declarations are always fully resolved and
lazy resolve will do nothing.
Kotlin annotations can be called without named parameters even if their
names are different from `value`. So there's no need to search for the
property named "value", since there might be none
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
The main reason is a bug in deserialization(KT-55357) that doesn't allow
to deserialize some binaries compiled with that feature enabled.
While we might fix it in 1.8.0, it doesn't help because previous
compilers, e.g. 1.7.0 still may break when using freshly recompiled
libraries.
Considering, that almost any meaningful fix might look unsafe for
the almost released 1.8.0, we can't enable the feature even in 1.9,
because 1.8.0 compilers wouldn't read those libraries anyway.
So, effectively this feature will be only enabled in K2.
^KT-55357 Related
^KT-36770 Related
This feature is not needed because it is unconditionally disabled for K1
(because of not fully correct implementation) and unconditionally enabled
in K2 (K2 does not support old behavior)
^KT-38895
Incompatible supertypes check also don't provoke runtime problems
in most situations, because this check is also bound to type argument
conflict. Related to KT-54411
Sebastian Sellmair