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
The situations with conflicting type arguments normally don't provoke
any runtime problems. Also, conflicts like A<T> VS A<SomeType> aren't
valid at all. Here we decided to remove them to avoid strange
and non-actionable warnings in user code.
#KT-54411 Fixed
The original idea was in resolving of annotation type ref using only
importing scopes and accepting or discarding that resolution result
depending on if this annotation is needed for compiler/plugins or not
But there is a problem that resolution of FirUserType with type resolver
is not a pure operation: type resolver transforms qualifier parts which
may contain type arguments, so if they were unresolved at the first
resolve, they will stay unresolved forever. To prevent this we will
deeply copy annotation type ref before first resolution
^KT-55286 Fixed
Denis.Zharkov