Otherwise behavior might change because enhancement may force computation
for other type parameters in cases like:
class A<X extends Y, Y extends X> {}
See the test:
org.jetbrains.kotlin.checkers.DiagnosticsTestGenerated.Tests.J_k#testRecursiveRawUpperBound3
We have an invariant that their lower bound is always
SomeType<Any?> and their upper bound is SomeType<*>.
Ehancing the latter to SomeType<out Any> making
lower bound not being a subtype of upper bound that breaks contract
for flexible types (fails with exception)
- Rename NullabilityQualifierWithApplicability -> JavaDefaultQualifiers
- Use JavaDefaultQualifiers instead of JavaTypeQualifiers for default qualifiers
This change is intended to make code more clear and to allow add some additional
parameters specific for default qualifiers needed for codeanalysis annotations
This way, the order in stubs and in deserialized text would be the same
On the next stub version bump, this fix should be reworked: the order
in the `DeserializedMemberScope` should be restored, and the order in
the stubs should be fixed to match the order in `MemberComparator`
^KT-41859 Fixed
- See the documentation for `DeserializedMemberScopeHelper` for the full
info about the fix and the issue
- Add `preserveDeclarationsOrdering` setting to
`DeserializationConfiguration`
- Enable this setting in `DeserializerForClassfileDecompiler`
- Also, use `List` instead of `Collection` to pass members to
`DeserializedMemberScope`. It is done to emphasize that the order of
the members is important and may be used
- Review: https://jetbrains.team/p/kt/review/1627
- ^KT-41346 Fixed
Change the signature of the `computeNonDeclared*` methods so they expect
mutable lists - it better suits their contracts. Also, add a little
documentations about the contract
Also, change `Collection` to `List` for incoming protos to `emphasize`
that their order might be used
Declarations inside that class are referencing the type parameters of
the containing function anyway, since we don't do any remapping. So the
resulting IR is slightly more correct, and doesn't lead to type
parameter/argument size mismatch error on IrBased/Wrapped-descriptors.
This reverts a part of 01da7f289b, which looks like it was no longer
necessary after 8d0ffa1444.
#KT-42028 Fixed