In case of null qualifier, we should not look into any static scope
NB: factory::createCallableProcessor returns NoExplicitReceiver processor
in case of null-receiver, that makes resolving the call in the test as
`property(::key)` that matches to the property itself, thus leading to
overload resolution ambiguity
^KT-35887 Fixed
Expression type serves as a part of a key for retrieving smart cast info.
Rewriting expression type with SmartCastManager leads to incorrect processing of following smartcasts for same expression, therefore it was removed.
KT-32507 Fixed
KT-32358 Fixed
It's necessary because of new type substitutor is eager than odl, so
if there is a substitution of type parameter deep inside type arguments
then second substitutor wins against first
#KT-35896 Fixed
Since there's no nullability assertion, null could end up in this list
and cause NPE further at `reportNotAcceptedExperimentalities`. This
could happen if a declaration was annotated with WasExperimental, the
marker was annotated with the new RequiresOptIn, and API version 1.2 was
used.
No new tests are added because 1.2 is obsolete and WasExperimental is
internal.
Also,
1. remove some redundant copies;
2. fix remapping of non-local returns in lambdas if the body is moved
after LocalDeclarationsLowering (the lambda is no longer inside the
body, but must still be visited)
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)
See the test and the issue for the clarification
After the change 7898922066
the expected type for "a" in expression "foo(a)" is A<E & B<*>>
But we have the original type A<E> and smart-casted enriched type A<B<*>>
(non of them is a subtype of A<E & B<*>>)
and fail in checkTypeInternal when checking types in during completion
^KT-35844 Fixed
Old version handled only private companions correctly.
Some situations require multiple companion object accessors
(including accessors for protected companion objects from supertypes)
to be generated in the corresponding class.
The JVM IR backend was producing class names with "<no name provided>"
for unnamed functions (i.e., `fun(...) {}`). This produces class files
with names invalid in Windows. This change adds validation of names
using the same set of invalid characters used in the frontend, which
should ensure class file names are valid.
Rename and refactor interface delegation phase. It didn't actually do
what was said on the box. It should be more in line with the
intentions of the phase now.
Wrapped descriptors are still used in reporting of the "conflicting JVM
signatures" diagnostic in the JVM IR backend, and TODOs in
implementations prevent that diagnostic from being shown, obscuring even
the place where the error happens.
Mikhail Glukhikh