The expected format was Kotlin language version (e.g. `2.0`), however the actual passed values were Kotlin release versions (e.g. `2.0.0`)
^KT-65986 In Progress
[KAPT] KT-65684 Set languageVersion=1.9 in KaptToolIntegrationTestGenerated
[KAPT] KT-65684 Re-enable a few now-passing tests in Kapt4IT
[KAPT] KT-65684 Fix the logic setting -Xuse-kapt4 flag in Kapt4IT.forceKapt4()
The change is needed to make sure that all the tests have the flag set,
otherwise some of them would silently switch to the fallback node.
Also disables a few now failing tests.
[KAPT] KT-65684 Revert "KT-64385 Enable K2 KAPT by default"
This reverts commit 7e9d6e60
Merge-request: KT-MR-14291
Merged-by: Pavel Mikhailovskii <Pavel.Mikhailovskii@jetbrains.com>
- remove ENABLE/COMPATIBILITY because they can no longer be used
- remove forAllMethodsWithBody because its behavior is now equivalent to
isEnabled
- inline isCompatibility
- inline DEFAULT
- rename ALL_INCOMPATIBLE -> ALL
Duplicated messages in testdata appeared because default renderer
renders diagnostic spans ambiguously. It shows only start position.
In fact, there are 3 failures, 2 of them distinguish only by the
diagnostic end offset. See youtrack for more information.
The issue about inconvenient rendering is KT-64989.
#KT-64608
These arguments switch language features which cannot be disabled
anymore because they're enabled from some LV not later than 1.4, and the
minimal supported LV is currently 1.4.
Pass the metadata serializer instance instead. This allows to further
reduce code duplication by introducing the common interface
`KlibSingleFileMetadataSerializer` for abstracting away K1 and K2
representation of a source file, as well as reusing
`Fir2KlibMetadataSerializer` across different backends.
KT-64392
- Shared application environments can be disposed in the middle of test
plan execution when the project count reaches zero. So resetting
`ApplicationManager` only on "test plan execution finished" is
incorrect, because it does not account for that scenario. Instead, we
should reset `ApplicationManager` every time the application
environment is disposed.
- We should also keep the manual reset in `testPlanExecutionFinished`
because `disposeApplicationEnvironment` may not need to dispose
anything if there isn't a shared application environment, but we
should still reset `ApplicationManager` if an unshared application
environment was created.
- This fixes "Some test disposed, but forgot to clear MockApplication"
exceptions which appeared after KT-64099 because it opened up proper
disposal of the shared application environment (instead of it being in
a state of leakage because not all project disposables were properly
disposed).
^KT-63650
^KT-64099
3aa84906 changed native metadata serialization to use proper platform
session, but it caused a new bug: FirKLibSerializerExtension uses
FirProvider from the passed session to get a containing file of
serialized declaration to put some extension into the metadata. And
platform session doesn't contain information about any declarations
except platform ones
So it's needed to use the proper FirProvider in it, which can be
extracted from Fir2IrComponents. This provider contains providers from
all sessions that are being compiled plus providers for top-level
declarations generated by compiler plugins
^KT-65024 Fixed
The trove4j library is licensed under LGPL, and that causes some troubles while working with it. The fastutil library provides the same functionality in the context of our needs, and is licensed under the Apache license.
^KTI-1135 In Progress
Invocation of Logger.fatal() may cause severe side effects such as
throwing an exception or even terminating the current JVM process
(check various implementations of this function for details).
The code that uses Logger.fatal() sometimes expects a particular kind
of side effect. This is totally a design flaw. And it's definitely not
a responsibility of Logger to influence the execution flow of
the program.
While not beeing final solution, this is closer to what
we want to have in the end. Enabling on non-JVM targets
would help better testing.
Enabling in JVM is now not possible yet, as some of the bugs are
not fixed yet (check KT-61360 for details)
^KT-62476
Add cache for reflection lookup of CLI arguments.
Replace CLI argument list with map.
The current cli parser tries to match every possible command line
argument against each command line argument, essentially in a double
loop. This fix replaces one of the loops with a map lookup. Building the
map is not expensive, and pays for itself even with a modest number of
parameters. The map is cached between calls, making subsequent calls
much cheaper. If run in a daemon, repeatedly parsing, e.g., 250
arguments, this speeds up argument parsing by a factor 20.
Disallow -shortName=value in CLI arguments.
Co-authored-by: Troels Lund <troels@google.com>
- This helps to track down disposables which are never disposed, and
reduces confusion when printing disposables in general (the names will
now be meaningful, instead of endless lists of "newDisposable" and
"TestDisposable").
^KT-64099
- The disposable passed to `getOrCreateApplicationEnvironment` should
not actually be the application environment's disposable, which is
created inside the function. Instead, it should be the project's
disposable, which is used to track how many projects still rely on the
shared application environment.
- This issue wasn't apparent before because there is no visible
consequence when an application isn't disposed after all projects have
been disposed (during tests). However, the solution for KT-63650
relies on application environments being disposed after all projects
are disposed, so that a new application environment with a different
configuration can be created. (Only one shared application environment
may be active at the same time.)
^KT-63650
The reason of this change is to make messages (especially warnings)
that are reported by the KLIB resolver become visible to the end user.
This can be achieved to forwarding such messages to the appropriate
compiler's components such as
`org.jetbrains.kotlin.cli.common.messages.MessageCollector` and
`org.jetbrains.kotlin.ir.util.IrMessageLogger`.
Also: The default `DummyLogger` should be used as minimal as possible.
Because it just forwards messages to the standard output (console)
where they can remain unattended. When the compiler is executed
from the Gradle plugin such messages appear only in DEBUG Gradle's log.
^KT-63573
The problem here is that for common session we register `FirJavaElementFinder`
which provides light classes based on expect classes. And then
at the start of analysis of jvm module we register one another
`FirJavaElementFinder`, which sees actual classes and uses them to
build light classes
But, because class ids of expect and actual class pair are the same and
element finders are ordered by creation order, when java resolve tries
to resolve some class, it founds light class based on expect class,
even if we are already in platform session
To fix this problem, it was decided to unregister all previous element
finders on creation of each new session, so old finders won't interfere
with analysis
^KT-63612 Fixed
^KT-64296
Alexander.Likhachev