`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>
`listOf`, `setOf` and `mapOf` overloads were defined in some source-sets
but common source-set was missing it.
This change adds common definition of these methods and also add
declarations for source-sets that were previously
missing it.
^KT-42589 fixed
* Explain what obsolete means and why workers are obsolete
* Add some documentation to workers to explain its common pitfalls
^KT-54702
Merge-request: KT-MR-9563
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
Motivation:
Users often expect simple patterns, like `[a]+` or `[^a]+`, to work fast
and without any problems, even with long strings.
Char class from the first pattern matches only 'a' and gets wrapped into
LeafQuantifierSet, and works fine with long strings indeed.
Char class from the second pattern, however, matches any character
except 'a', including supplementary code points. So, the number of chars
it consumes is not known beforehand. There is no optimization for such
char classes, and if they are matched multiple times, the stack memory
gets exhausted.
Modification:
Introduce FixedLengthQuantifierSet node.
The node represents quantifier over constructs that consume a fixed
amount of characters for a given string and index. Such constructs don't
need backtracking to find a different match. Thus, it is possible for
the node to avoid recursion when matching multiple times.
Result:
Fixes KT-46211, KT-35508 and probably KT-39789. Reproducer for the
latter issue is no longer available, but error stacktrace resembles
those of the other issues.
Motivation:
Calling AbstractCharClass.setNegative always leads to
mayContainSupplCodepoints being `true`, even when `alt` is already
equal to the argument. Given that CharClass always calls setNegative
with its constructor parameter - `negative`, mayContainSupplCodepoints
always gets set. i.e. `[a]` will have mayContainSupplCodepoints set.
mayContainSupplCodepoints affects what node (RangeSet or SupplementaryRangeSet)
wraps this char class. See Pattern.processRangeSet.
RangeSet is better optimized and avoids recursion when it is quantified.
Modification:
Set `mayContainSupplCodepoints` flag only when `alt` is updated.
When `alt` is updated, this char class gets inverted, hence now may
contain supplementary code points.
Otherwise, content of this char class does not change, i.e. no new
supplementary code points is added.
Result:
Fixes KT-46211.
Motivation:
The node was never used. Perhaps, it was copied from apache harmony
but ultimately, despite possible performance impact, SequenceSet was
used instead. See Pattern.processCharSet and AbstractSet.first.
The performance impact wouldn't be noticeable anyway.
Modification:
Keeping unused code in project is not a good practice, so get rid of it.
Result:
Less code to maintain.
* Provide short-circuit methods for contract "EnumEntries contains all
enum entries"
* Make EnumEntries serializable
* Introduce more convenient overload for other backends
#KT-53152
Merge-request: KT-MR-6867
Merged-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
But still cherry-pick them when serializing builtins because they are
used in builtins signatures.
Merge-request: KT-MR-6488
Merged-by: Ilya Gorbunov <Ilya.Gorbunov@jetbrains.com>
Filipp Zhinkin