The Android build pipeline can extract embedded proguard configurations
from dependencies and merge them automatically. This adds a conservative
proguard configuration to the kotlin-reflect JVM artifact in support of
that. This focuses mostly on just retaining what's necessary for
kotlin-reflect's own functionality to operate, but could be expanded if
community feedback discovers other good candidate rules.
With this in place - most Android projects using R8 or Proguard should
Just Work™️ with kotlin-reflect.
Like other classes declared in the standard library, construct a mock of
it in JvmSymbols. This is needed to move classes in kotlin.reflect out
from builtins and to the JVM part of the standard library.
It partially reverts 7898922066
because it's not obvious that it's a safe operation
for invariant/contravariant types.
Also, there's a necessary fix in prepareReceiverRegardingCaptureTypes
to make types order stable
Otherwise test bareTypesWithStarProjections becomes flaky.
Also, the changes in bareTypesWithStarProjections.kt are also expected
because the type of the expression `coneSymbol` after the second "if" is
FirVariableSymbol<*> & FirPropertySymbol & AbstractFirBasedSymbol<*>
thus we fix D in the call `coneSymbol.phasedFir()` to FirVariableSymbol<*>
because it's the first type in the list
(see the next line after the last changed in AbstractTypeChecker)
Prevent stack overflow during uncapturing of star projection
for parameter with recursive upper bound.
Uncapture star projections for flexible type parameters with
respect to flexible upper bound.
^KT-35210 Fixed
It's only needed in old FE to avoid clashes when initializing DI
The main idea is gettind rid of intermediate interfaces because
each of them adds another intermediate DefaultImpls call
* JVM incorrectly mapped T<KClass<...>> to T<Class<...>> because the
annotation-ness of the type mapping mode was inherited one level
down into a generic signature independent of T
* JVM_IR was even worse as it did not use VALUE_FOR_ANNOTATION at all,
mapping T<T<KClass<...>> to T<T<Class<...>> as well.
The correct behavior is to map KClass to Class only at top level or as
an argument of Array.
With NO_LOCKS strategy we can easily end up in a situation when
constraint system for a generic call is built incorrectly,
producing flaky errors (or don't produce errors at all)
Now proper storage manager is injected for all cases except:
- IR
- Codegen
- Serialization plugin
- Fake local objects
Most likely, NO_LOCKS strategy for these cases is fine as at that point
the compiler works in one thread
#KT-34786 Fixed
returns Unit. The reason is the same as in the previous commit.
If the callable is tail-call and its callee returns something other that
Unit and suspends, on resume the result of the call will not be Unit.
#KT-34703
Otherwise this brings incompatibility between kotlin-reflect 1.3.70+ and
kotlin-stdlib 1.3.60-.
This commit reverts the relevant parts of c164745301, 5c89f2fa54 and
896512f7cd.
Consider a call like `select(1, "")`, the resulting type for it is
Comparable<Int & String> & Serializable.
After variable fixation, the compiler incorporates this type into the
constraint system to check for a contradiction, so it checks
applicability of argument to the resulting type.
In other words, for the above call it checks is
`Comparable<Int & String> & Serializable` subtype of `IntegerLiteralType`?
Which ends up in checking is `IntegerLiteralType` subtype of `Int & String`.
Before this commit, such check was leading to the false result, but
because of losing diagnostic (which was fixed in the previous commit:
29f591b1), there was no error
Zac Sweers