Properly set up dom-api-compat dependency for JS IR tests. Since this dependency is added
automatically for every Kotlin/JS library, it should be present during tests just as stdlib.
As a result, tests for serializable enums were changed since 1.6.0 runtime does not require enums to be explicitly serializable.
^KT-61573 Fixed
Review: https://jetbrains.team/p/kt/reviews/11969/timeline
Tests:
- MultiPlatformIntegrationTestGenerated
- CliTestGenerated
- MultiPlatformIntegrationTestGenerated
- DiagnosticTestGenerated.Multiplatform
- FirLightTreeOldFrontendDiagnosticsTestGenerated
Also add -Xexpect-actual-classes flag to all necessary ./libraries/* modules
Otherwise compilation of those modules failes because of `-Werror`
We have `BackendKinds.IrBackend` for IR emitted by the frontend.
We need a different backend kind for IR deserialized from klibs.
We cannot use `BackendKinds.IrBackend` for that purpose, because we
cannot have two different `IrBackendInput` subclasses with the same
kind.
We need a different `IrBackendInput` subclass for deserialized IR
because the `IrBackendInput` for frontend-emitted IR contains some
properties like `sourceFiles` which don't make sense for
deserialized IR.
Since we now have two backend kinds for IR artifacts, we need to make
certain functions and classes in the test infrastructure generic
over backend kinds.
Note: the JsIrDeserializedFromKlibBackendInput class is not used
anywhere yet. We will use it in the coming commits.
According to
`FirNativeCodegenBoxTestGenerated.testNestedClassesInAnnotations`,
the annotation
`kotlin.internal.PlatformDependent` is
unresolved reference.
^KT-58549 Fixed
Pinning the language version is rarely the right thing to do.
This changes makes it harder to do so by requiring an additional
directive with a name that indicates to developers that they are
likely doing something dangerous.
We can use less strict rule for produced annotations:
* Previously: the same annotations from `findAnnotation` and `annotations`
have the same identity
* Now: the same annotations from `findAnnotation` and `annotations`
are equals by 'equals'
^KT-56046
Review: https://jetbrains.team/p/kt/reviews/6753
All redundant I managed to find, of course.
Why: I'm going to process all reflect dependencies in the next commits.
Cleanup reflect dependency before processing.
They are redundant because:
1. if `compileOnly` then compilation didn't break after dropping the
dependency
2. if `test*` then tests didn't break after dropping the dependency.
3. `analysis/analysis-api-fir/analysis-api-fir-generator/build.gradle.kts`
`compiler/fir/checkers/checkers-component-generator/build.gradle.kts`
Drop `implementation(project(":kotlin-reflect-api"))` because the
module already depends on
`implementation(project(":kotlin-reflect"))`
4. `compiler/daemon/daemon-client/build.gradle.kts`. Drop `runtimeOnly`
because after dropping `compileOnly` compilation didn't break (so
`runtimeOnly` looks suspicious). Less safe than 1-3
Previously, we resolved all declaration to the TYPES phase to collect their sealed inheritors
and thus not really checking lazy resolution to TYPES.
Now sealed class inheritors collection happens in separate LLFirResolveSession
The constraint system for the old type inference is going to be removed.
Also, `CONSTRAINT_SYSTEM_FOR_OVERLOAD_RESOLUTION` isn't used in the production
Original `ComponentRegistrar` exposes Project to its registration method,
so plugins should manually register extensions to it. To prepare for
possible unbound compiler from Project API in future new `K2ComponentRegistrar`
introduced which provides registration method without Project at all
This is needed to unbound CompilerConfigurationProvider from ApplicationEnvironmentDisposer,
which depends on classes from JUnit 5. This will allow to safely use
compiler test framework with base test framework different from JUnit 5
along with source lines mapping, allows to "emulate" usage of the
PSI files which allows to extract source file and line mapping info
on every stage from source element.
It makes sense to use this mapping for the error reporting too.
Always serialize type table (and version requirement table) after
everything else, to prevent bugs like KT-51446 where inline class
underlying type was added to the type table after it has already been
serialized.
#KT-51446 Fixed
Leonid Startsev