These tests were initially testing that $EntriesMappings classes were
correctly generated, but started to check something else once the
language feature EnumEntries was enabled by default.
Previously, we applied type arguments as is when converting type alias
constructor calls to IR.
Now, we map them using the expansion of the type alias.
#KT-59743 Fixed
In early prototypes of interpreter, it was easier to assume that
all classes from Java can be interpreted and fix something if not.
Check for Java declaration was done by checking that the package name is
starting with "java". But this is actually wrong and can lead to errors
when some code is declared in "java" something package, but is not from
Java stdlib.
#KT-60467 Fixed
A new resolution diagnostic UnsuccessfulCallableReferenceAtom is
introduced that is used in EagerResolveOfCallableReferences.
No diagnostic is reported on unresolved calls with this diagnostic
because
#KT-59856
This allows us to properly complete array literals arguments of
annotation calls fixing several false-negative type mismatch errors
as well as enabling the inference of generic type arguments.
#KT-59581 Fixed
#KT-58883 Fixed
This lets us properly complete the call which fixes some issues with
false-positive type mismatches.
This change doesn't apply to array literals in annotation calls yet
because they are resolved as context-dependent.
This will be adapted in a following commit.
#KT-59581
It is required to avoid leakage of annotations instance from
the original type
It should be enough to just create a new instance of an annotation
without a deep copy, because transformer shouldn't touch it
^KT-60387 Fixed
Support CALL_TO_JS_MODULE_WITHOUT_MODULE_SYSTEM diagnostic
^KT-59377 Fixed
Support CALL_TO_JS_NON_MODULE_WITH_MODULE_SYSTEM diagnostic
^KT-59381 Fixed
Support CALL_FROM_UMD_MUST_BE_JS_MODULE_AND_JS_NON_MODULE diagnostic
^KT-59417 Fixed
This is basically a workaround for a slightly different IR generated by
fir2ir vs psi2ir. Simplified, psi2ir generates something like this for
the sample from KT-59218:
TRY type=Unit
try: BLOCK type=Unit
VAR methodHandle [...]
TYPE_OP type=Unit origin=IMPLICIT_COERCION_TO_UNIT
CALL invokeExact [...]
While fir2ir generates the following:
TYPE_OP type=Unit origin=IMPLICIT_COERCION_TO_UNIT
TRY type=Any?
try: BLOCK type=Any?
VAR methodHandle [...]
CALL invokeExact [...]
The lowering relies on the fact that a polymorphic call (`invokeExact`
in this case) is a direct argument to the TYPE_OP, to determine the
correct return type (Unit in this case) to be generated in the bytecode.
The solution here is to push the type coercion "through" all the
block-like structures (`try`, `when`, container expression) so that if
the last statement in the block is a polymorphic call, it gets properly
converted even if the whole block is under a type coercion operation, as
it happens in fir2ir. We achieve that by using the "data" parameter of
the IR transformer: appropriate immediate children of
IrTypeOperatorCall/IrTry/IrWhen/IrContainerExpression get the type that
the expression needs to be coerced to, and all the other expressions
ignore that type and set it to null when transforming their children.
A proper solution would be to ensure fir2ir generates exactly the same
IR as psi2ir (KT-59781), but since PolymorphicSignatureLowering is the
only lowering affected so far, and polymorphic calls occur very rarely,
it seems safe to workaround it in the lowering for now.
#KT-59218 Fixed
This is important for IR lowerings like PolymorphicSignatureLowering
which are very sensitive about the correct types of expressions and
placement of coercions to Unit (KT-59218).
A boolean parameter to `insertImplicitCasts` is not the best solution to
ensure that coercion to Unit is added. The best solution would be to fix
the TODO and generate coercion to the block's type for the last
statement. But that will affect many other places and will need to be
done separately => KT-59781.
Code in IrInterpreter is uncommented to fix the FIR test
`compiler/testData/ir/interpreter/exceptions/tryFinally.kt`; otherwise
evaluation of the function `returnTryFinally` there crashes with
"NoSuchElementException: ArrayDeque is empty". No idea why this test
didn't fail for K1 though, since the created IR is exactly the same.
For some unknown reason this breaks WASM backend with K2, but not with
K1 => KT-59800.
Before this change, it could happen that `when` of type Unit has a
branch whose type is not Unit. This can lead to problems in IR
lowerings, for example PolymorphicSignatureLowering which is very
reliant on the correct types of expressions and placement of coercions
to Unit (KT-59218).
Use it in diagnostic tests with JVM backend instead of the
RENDER_DIAGNOSTICS_FULL_TEXT directive.
This is needed because otherwise in
AbstractDiagnosticsTestWithJvmBackend there are two handlers trying to
dump full diagnostic texts: JvmBackendDiagnosticsHandler and
FirDiagnosticsHandler, which dump different diagnostics (reported by
backend vs frontend) and in slightly different formats.
In fact, this is why exceptionFromInterpreter.fir.diag.txt was added in
48484368c7: the existing .diag.txt was detected as incorrect by
FirDiagnosticsHandler (even though the diagnostics are the same, just
printed in a different way), which led to the creation of .fir.diag.txt.
For these tests, the behavior about checking diagnostic text in
FirDiagnosticsHandler is useless because it doesn't include backend
diagnostics. So we disable it by using another directive.
Remove the "_ir" suffix. It was originally used to distinguish tests on
the JVM IR backend from the old JVM backend ("_old"), but the latter are
removed now.
Also take into account diagnostics reported via
GenerationState.collectedExtraJvmDiagnostics, and render them in the
similar format to KtDiagnostic.
Don't make the test pass if the reported list of diagnostics is empty,
because that defeats the purpose of the test.
Instead of checking for only open declarations, check for overridable
declarations, since private declarations cannot be overridden even if
they are marked as open. While normally these modifiers are exclusive,
a declaration can be made open via a compiler plugin like AllOpen.
#KT-60183 Fixed
#KT-57223 Fixed
Alexander Udalov