^KT-59665 Fixed
Review: https://jetbrains.team/p/kt/reviews/11039/timeline
It's better to have this logic in common place
(AbstractExpectActualCompatibilityChecker) to avoid missing compilation
errors in the future
This commit fixes:
1. Missing compilation error for actual function with default arguments
for 'actual typealias' KT-59665
2. Missing compilation error for actual function with default arguments
for actual fake-override KT-59665
Alternative solution for KT-59665 is to create a special checker.
"incompatibility" vs "special checker":
Arguments for common incompatibility:
- What if we had a rule that expect and actual default params must
match? If so then it certainly would be an incompatibility.
- Technically, we do the matching of expect and actual params (because
we allow default params in common ancestors of expect and actual
declarations).
- It's hard to check that the actual definition doesn't use default
params because `ExpectedActualResolver.findActualForExpected` filters
out fake-overrides and doesn't return them. It's not clear logic for
me, that I'm afraid to touch.
implicitActualFakeOverride_AbstractMap.kt test breaks if you drop this
weird logic
- WEAK incompatibilities can be considered as "checkers". So it doesn't
matter how it's implemented, as a "incompatibility" or a "checker"
Arguments against common incompatibility:
- Although we match expect and actual declarations to allow default
params in common ancestors of expect and actual declarations, it's
still can be considered that we check that the actual declaration
doesn't have default params. And it doesn't feel right that we check
correctness of the actual declaration in expect-actual matcher.
- ~~It may change the rules of expect actual matching~~ (It's not true,
because ActualFunctionWithDefaultParameters is declared as WEAK
incompatibility)
Modification registration seems to changed in Java 9. Now if the asked
capacity in `ensureCapacity` function is less than current capacity,
no modification is registered.
Instead of access by index. To avoid performance issues
when the subclass `get(index)` has non-constant time complexity.
It also aligns behavior with JVM.
`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.
Nikita Bobko