It's going to be deprecated in Gradle 8.3
There's currently no way to pass a `org.gradle.api.provider.Provider` to the JavaExec.systemProperty or Test.systemProperty. There's a workaround using `org.gradle.process.CommandLineArgumentProvider`, but I intentionally don't rework these calls as Gradle is going to allow passing providers to configure system properties: https://github.com/gradle/gradle/issues/12247#issuecomment-1568427242
^KTI-1473 In Progress
We cannot use only non-local declarations as anchors due to the same
resolution logic between member declarations of local classes, so we
have to support such cases as well
^KT-63042
`IrGeneratedDeclarationsRegistrar` assumes that all generated functions
are correct from a Kotlin point of view. But `writeSelf` method on JVM
is a static method outside any object/companion object
So to properly calculate containing class for this method we should
generate a dispatch receiver parameter, register the method in metadata,
and then remove the parameter (to make function static)
Separate class allows encapsulating comparison, equality, and structure of version parts.
It also makes more sense from API standpoint than plain `IntArray`.
To make sure that the correct version and flags are preserved during metadata transformation,
they are now stored inside KotlinClassMetadata.
Such change also makes it possible to make write() a member function of KotlinClassMetadata, further simplifying API.
Also, it allows tracking whether readStrict or readLenient was used to read metadata and prohibit writing accordingly.
Also provide transform() method as a shortcut for readStrict+write.
Related to: #KT-59441
In strict mode, an exception will be thrown when inconsistent metadata is encountered. In lenient mode, the reader will attempt to handle the inconsistent metadata by ignoring certain inconsistencies. This is a solution to a problem of reading metadata 'from the future' that is not allowed by default, but desired in certain cases. See updated ReadMe for details.
Also fix problem with Strict Semantics flag.
#KT-57922 Fixed
#KT-59441 Fixed
If a serializable class has generic type parameters, its serializer is not an object
and has a specialized constructor. This constructor was public in K1 and should
be public in K2 so it can be called from other serializable classes
(in case class is e.g., part of sealed hierarchy).
#KT-63402 Fixed
This diagnostic used an incorrect type for rendering (outer class type instead of a property type)
and didn't expand type argument of `KSerializer`.
Also add an additional test case for generic parameters.
#KT-63570 Fixed
To be more consistent with K1, certain diagnostics should be reported
not on the whole properties' types, but on type arguments inside them.
Note that there is still a difference with K2 because K2 reports on a type argument
including its annotations, while K1 used KtTypeReference.typeElement.
IMO, K2 conveys the same or better meaning here, so I am willing to leave this
difference instead of providing PositioningStrategy.
#KT-53861 Fixed
Since JDK 17+ pretty-printer does not print parens on empty annotation
parameters, print them anyway. Otherwise, tests with annotations differ
on different JDKs.
#KT-57389
Previously, some tests have also been disabled on JDK 11+, since
we did not filter out empty filesets, which led to failed assertion
inside JDK.
#KT-57389
This change improves performance, as
checking callables via scopes in
`4e587157` turns out to be quite
slow, and it also prevents some redundant
diagnostics.
IrStatementOriginImpl and IrDeclarationOriginImpl were made final
classes to simplify the creation of them (a delegate provider was
added) and to optimize performance when comparing the origins by type
and name
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.
A previous fix to the generator made the generator and checker
validation of classes which could be parcelized different. The checker
would report error in cases where the generator would not generate
anything. Align these checks, with improved code sharing, so errors are
not reported on classes which will not have parcelize components
generated.
^KT-63086 Fixed
Alexander.Likhachev