Before post-processing was able to handle only one converting file at once
So, some conversions (like (field, getter, setter) to Kotlin property)
was not able to work when converting class hierarchy was split into
multiple files.
Also, inferring nullability for a set of files was broken
#KT-19569 fixed
#KT-34266 fixed
#KT-32518 fixed
It will update usages from files not in conversion scope to a valid ones:
1. When converting (field, getter, setter) triple from Java to a Kotlin property,
it will:
1. Update every usage of getter/setter in Java/Kotlin code to a usage of actual property
2. If property is used in Java directly then will add @JvmField to it
2. When converting static method or static field without getter and setter, which has Java usages then add @JvmStatic to it
#KT-34164 fixed
* Fix adding new items (which was untested, as the logic was only tested
by unit tests)
* Exclude the source set's dependsOn transitive closure from the
requiresVisibilityOf checks (i.e. these source sets are considered
visible)
* Fix minor issues in the `UnsatisfiedSourceSetVisibilityException`
message
* Add `requiresVisibilityOf` to integration tests
Issue #KT-34312 Fixed
There was a problem with `reportDiagnosticOnce` method which was
called, for example, to report diagnostics about experimentalities. It
was crucial for code as in the issue (KT-34204).
The whole complexity was "count of experimental diagnostics" multiply
"count of all diagnostics" multiply very large constant. Almost on
each `reportDiagnosticOnce` method `readonlyView()` was called which
in turn called computation of cache. During cache computation we were
iterating through the all diagnostics and also were using
KotlinSuppressCache, which is not very fast.
#KT-34204 Fixed
since we're not always use jna (means that we can get warnings about missing jna libs)
and according to the IDEA team, NIO2 works well enough to rely on it
This patch adds a group of shortcut DSL methods allowing a user to
create simulator and device targets for Apple platforms along with
corresponding common source set(s) in one command. iOS, tvOS and
watchOS targets are supported.
Issue #KT-33856 fixed
This fixes the problem where compiling a class initializer that contains
a call to an `assert`ing function in a separate module causes the
assertion to always be enabled (i.e. the attached test used to fail in
CompileKotlinAgainstInlineKotlin mode).
Ivan Gavrilovic