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.
This is important for calls using reflection as the reflect
library assumes this ordering of arguments.
It would be nice if this could be handled in the lowerings.
Currently AddContinuationLowering is after
DefaultArgumentStubGenerator. If we could add the continuation
first and then do default stub generation maybe we could avoid
the reshuffling introduced in coroutine codegen in this change.
The first change here is swapping the isCompatibility and hasJvmDefault
checks. Otherwise behavior could be different depending on -Xjvm-default
mode even for non-JvmDefault declarations, which makes little sense.
Another change is avoiding generating $default stubs for fake overrides
in interfaces, which replicates the behavior of the current backend.
(Note that this change also fixes the first problem on the newly added
tests, but the first change seems useful anyway.)
This only reproduced when compiling (technically incorrect) code in the
standard library, where private functions monitorEnter/monitorExit are
accessed from another file, and their names with suffixes are not
recognized as intrinsics which should be replaced by
monitorenter/monitorexit JVM bytecode instructions.
SyntheticAccessorLowering was initially implemented under the assumption
that any access to an invisible declaration will cause an accessor to be
generated _in the same file_. Moreover, it's declared in the group of
phases that are performed by file.
But this assumption is incorrect for constructors which need to be
hidden (those which take parameters of inline class types), since such
constructor is public and can be called from anywhere. In this case,
SyntheticAccessorLowering actually generated a new accessor for the
hidden constructor for each (!) source file where that constructor is
called, which led to ClassFormatError because of the class file having
multiple methods with the same signature. The internal `functionMap`
cache didn't help because it's not shared among phase instances for
different files (well, it helped to generate not more than one accessor
per usage-file).
In this change, we use the global cache, stored in JvmBackendContext,
for accessors to hidden constructors. Note that after this change, calls
to hidden constructors are always transformed to the corresponding
accessor in SyntheticAccessorLowering right away, but that accessor
might be orphaned for a while (not declared in any parent's
declarations). Only when SyntheticAccessorLowering encounters the
original constructor which needs to be hidden, it adds the accessor
beside it.
The test is sensitive to the file order, so both variants are added.
See KT-35849.
1. When expected lambda return type is a type parameter, don't generate
introduce implicit casts (even if the corresponding type parameter has
an upper bound that would otherwise require such cast).
2. Do not generate implicit null check for lambda return value of
@EnhancedNullability type.
Rename fictitiousFunctionSymbols -> syntheticFunctionalInterfaceSymbols
Support suspend function interfaces
Add supertypes for KFunction / KSuspendFunction
Currently FirThisReceiverExpression of instance methods are translated
to references of the class' thisReceiver,
not the method's dispatch receiver,
which causes problems with IrFrameMap::typeOf,
as the class' thisReceiver is not in the typeMap.
This commit translates non-qualified "this" references of
instance methods to references of the methods' dispatch receiver.
Local functions raised in LocalDeclarationLowering continue to refer to
type parameters that are no longer visible to them.
This commit only adds new type parameters to their declarations, which
makes JVM accept those declarations. The generated IR is still
semantically incorrect (needs further fix), but code generation seems
to proceed nevertheless.
Whenever we want the default 0/null value for a type we need to
check if it is a non-nullable inline class type and produce
the right value for the underlying type.
#KT-35740 fixed
also add tests and drop logger usage in the cli dependencies manager:
the logger is normally unitialized in the usage scenarios, but related
warnings are annoying.
Alexander Udalov