It is now unneeded, and future needs should be possible to
be resolved otherwise.
Removing it will simplify further changes to tree generator,
especially for IR.
Because `public JvmTypeExtensionVisitor` was removed, a new place for `const val PLATFORM_TYPE_ID`
is required. It is logical to place it as a some kind of constant for Km node;
however, because it is platform-specific, there is a need for an empty
`KmFlexibleTypeUpperBound.Companion` in metadata common sources
and `public val KmFlexibleTypeUpperBound.Companion.PLATFORM_TYPE_ID`
extension in kotlin-metadata-jvm sources.
See also: KT-63156
This includes APIs such as:
- Visitors API
- Obsolete KotlinClassMetadata reading and writing API
- Extension and extension visitors API
- Flags and `class Flag` (a reduced version of it was moved to test sources)
- Various utility methods
Extensions mechanism got reworked with the removal of public visitors; it is
completely internal now with special accessors in kotlinx.metadata.internal
package.
Since `var KmClass.flags` is internal now (instead of being deprecated), special
utility functions with the name `_flagAccess` were added to internal package
for testing purposes.
^KT-63156 Fixed
K/N distPlatformLibs Gradle task dependended on hostInstall and
hostCache. The latter doesn't work (= has incorrect dependencies) on
hosts that don't support compiler caches for the host target (i.e.
Windows).
As a result, running distPlatformLibs task on Windows didn't work,
causing local test runs to fail.
This commit fixes the problem by making distPlatformLibs depend on
`"${hostName}PlatformLibs` instead, so it does the same as before but
handles the non-caching hosts correctly.
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
Dmitrii Krasnov