Do not include delegated field into generated constructor even though it
might have backing field.
Test that shows issue was added. Properties that are explicitly marked
as delegated are now excluded.
Fixes https://github.com/Kotlin/kotlinx.serialization/issues/2091
Once configured this property changed default language version
convention for all compiler options to '2.0'.
On usage, it produces a warning that it should not be used in
production.
^KT-57736 In Progress
There's a heuristic for approximation of a captured type that once
it has non-trivial lower bound (other than Nothing), it's worth
approximating it to sub-type even while the containing
top-level type is being approximated to super-type.
And that sounds reasonable in case the lower bound is indeed non-trivial,
but that's not the case because nullability here comes from
the nullability of captured type position.
So, the fix is basically not to treat such approximations as non-trivial.
And while that seems to be a bit of a change in the language semantics,
it still looks reasonable (see other changes in test data and KT-58087)
^KT-57958 Fixed
^KT-58087 Fixed
While plainly repeating K1 behavior might be a dumb solution,
but inventing another one might be quite complicated
because we need to stop fixing variables into Nothing in many cases,
but probably not in all of them (see KT-58232).
^KT-58149 Fixed
^KT-58232 Related
Android preset functions were moved to a separate interface
because we need to write custom deprecation with ReplaceWith
due KT-57903.
After that we had generated:
- all the K/N preset functions
- jvm functions.
I decided to move jvm function to separate file too,
so the whole division to several files would be somewhat sane.
I kept the KotlinTargetContainerWithPresetFunctions interface to
keep source/binary compatibility for the `android`/ `jvm` preset
functions users
#KT-57903 In Progress
Having only one SourceSet being associated with a KotlinCompilation
will simplify multiple code paths and prevents misconfiguration
from users.
^KT-58220 Verification Pending
See: KT-58234
See: KT-58235
`AtomicInt`, `AtomicLong`, `AtomicReference` and `AtomicNativePtr` classes were moved to `kotlin.concurrent` package. The corresponding classes from `kotlin.native.concurrent` were deprecated with warning since Kotlin 1.9.
In order to prepare for further commonization of Atomics API the following changes were made:
* `kotlin.concurrent.AtomicInt`:
* `increment(): Unit` and `decrement(): Unit` methods were deprecated with error
* New methods were added: `incrementAndGet(): Int` , `decrementAndGet(): Int`, `getAndIncrement(): Int`, `getAndDecrement(): Int`, `getAndSet(newValue: Int): Int`
* `kotlin.concurrent.AtomicLong`:
* `increment(): Unit` and `decrement(): Unit` methods were deprecated with error
* New methods were added: `incrementAndGet(): Long`, `decrementAndGet(): Long`, `getAndIncrement(): Long`, `getAndDecrement(): Long`, `getAndSet(newValue: Long): Long`
* Deprecated `AtomicLong()` constructor with default parameter value
* For all atomic classes `compareAndSwap` method was renamed to `compareAndExchange`
See KT-58074 for more details.
Merge-request: KT-MR-9272
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
We had false assumption that KotlinCompile tasks name will always start
with "compile" prefix, but our exposed api allows to create tasks with
random names. I've adjusted method to calculate kapt task names for any
KotlinCompile task name.
^KT-54468
Some `KtCallElement`s might never be resolved, and they won't even have
any kind of diagnostic from FE10 compiler. We don't want to log such
cases because it's not clear whether we can or should fix them in K1
plugin
LOG.error is still enabled for K2 plugin, since for it we want to catch
and fix all such problems
^KT-58249 Fixed
Adding or removing a method or property with
a default implementation to an interface should
invalidate all children: we must regenerate JS code for them
^KT-56237 Fixed
AngryGami