There's a separate test data directory `testsWithJvmBackend` with a
runner that properly invokes the JVM backend and reports diagnostics
from it. All tests where JVM diagnostic presence/absence is important
were copied/moved there in this and previous commits.
The problem with the code removed in this commit is that it invoked some
parts of the _old JVM backend_ and old light classes, which is very far
from what users see in the production compiler at this point. This led
to real issues where we implemented incorrect behavior in K2 based on
the misleading diagnostic report from the K1 test.
The diagnostic in `triangleWithFlexibleTypeAndSubstitution4.kt` was
removed, but there's a copy of this test in `codegen/box/javaInterop`
which fails for K2 (KT-66529).
The diagnostic in `intersectionWithMappedSignature.kt` was removed and
that is OK because at this point CONFLICTING_JVM_DECLARATIONS there
seems like a bug in the old JVM backend.
In fact the latest compiler (neither K1 nor K2) does NOT report an error
here, see KT-66522. The error was there in the diagnostic test because
the test used custom code which invoked parts of the old JVM backend to
report signature clash errors.
The issue is rather minor and is present since 1.5, so to reduce
confusion, the test is deleted.
#KT-66522
In this commit, tests where backend diagnostics were reported correctly
are being moved.
FirScopeDumpHandler was added to FIR diagnostic tests with JVM backend
to support `SCOPE_DUMP` in `overridesBuiltinNoMagic.kt` and
`charAtAndOverload.kt`.
This is basically a copy of the test
`diagnostics/tests/j+k/primitiveOverrides/triangleWithFlexibleTypeAndSubstitution4.kt`.
The diagnostic version of the test is not removed because it has
frontend-specific diagnostics `FIR_DUMP` and `SCOPE_DUMP`.
This test is copied to make it clear that it actually passes in K1, and
new errors in K2 here are technically a breaking change, see KT-66529.
The error CONFLICTING_INHERITED_JVM_DECLARATIONS was present there only
because diagnostic tests used parts of the old JVM backend to report JVM
backend diagnostics.
#KT-66529
- `typeParameterWithTwoBounds.kt` is already present in
`diagnostics/testsWithJvmBackend/duplicateJvmSignature/erasure/`.
- `clashWithCompanionObjectField.kt` is already present in
`codegen/box/fieldRename/jvmFieldNoClash1.kt`.
- `jvmFieldAndJavaGetter.kt` is already present in
`codegen/box/jvmField/noClashWithInheritedJavaMethod.kt`.
In case of two latter tests on JvmField, there's (correctly) no error
reported in JVM IR, which is why those are box tests.
Resolve it like a receiver of a call.
This makes the resolution result consistent with the equivalent
function call.
The K1 difference is covered by KT-66453.
#KT-66504 Fixed
In 9b5a9ccb `throws Exception` was removed from java test sources and
all checked exceptions were wrapped with `RuntimeException`
But it was forgotten that there is a `rethrow` utility, which doesn't
wrap exception but makes the javac happy at the same time
This is the first implementation of a control flow graph facade for the
extract function IDE refactoring. The exact contents of
'KtDataFlowExitPointSnapshot' will be refined later.
^KT-65762 Fixed
This is a step towards generating those classes. The code generator
won't care about default values in parameters,
and secondly, it will reorder some constructor parameters.
To keep source compatibility, new factory functions are created,
with the same signature as the constructor.
They will resist the change in order of constructor parameters.
Eliminating direct calls to constructors should also make further
refactorings a bit easier.
This change omits classes deriving from IrMemberAccessExpression,
as they are a bit more complicated
and will require separate effort.
#KT-65773 In Progress
Do not use `char[sizeof(T)]` as an internal utility replacement for `T` (e.g. in intrusive_list::head_).
It's UB to access members of such values before a propper constructor of T is called.
Merge-request: KT-MR-14076
Foreign values (such as '_DebugLabel' properties contributed by the
debugger) don't have a parent (or a valid source element in general).
^KTIJ-27382 Fixed
Since parcelize is Android specific, it should only be enabled for
Android compilation. In order to allow parcelize to generate code
for declarations in common code, we make checkers platform checkers
and we allow the registration of an additional annotations to
trigger parcelize processing.
That way, code such as:
```
package my.package
annotation class Parcelize
expect interface MyParcelable
@Parcelize
data class User(name: String): MyParcelable
```
Will work with an Android platform actual of the form:
```
actual typealias MyParcelable = android.os.Parcelable
```
And telling the plugin to trigger parcelize processing with the
additional annotation `my.package.Parcelize`.
Fixes https://issuetracker.google.com/315775835.
Strictly speaking, callable references are not calls. However, type
arguments are still inferred for references, and 'KtCall' is the only
place in Analysis API that exposes call-substituted types.
^KT-66485 Fixed
Artem Kobzar