This diagnostic may be reported even without any compiler plugins (e.g.
for annotation named `Target` or `Deprecated`), so the old name
and message were quite confusing
^KT-64654
Otherwise, if complex expressions such as when expressions are
used in combination with the intrinsics we get incorrect stepping
behavior.
^KT-64341 Fixed
- 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
(reuse anonymous initializers as block wrappers) so the top-level script
elements are all declarations now. Rename the property accordingly (
together with the previous commit).
It makes script more similar to the class and thus simplify e.g.
control flow analysis and resolve code.
same as they were in K1 (see KSerializerDescriptorResolver): internal for
final classes and public for non-final.
Unfortunately, there are no Klib API dumps tests in the compiler, so I tested manually.
#KT-64124 Fixed
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`.
Dmitriy Novozhilov