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.
The phase to eliminate redundant function prologue safepoints
was written in Kotlin which meant that it was performing a lot
of jni calls. Moving the simple optimization to C code speeds
things up dramatically.
On a large project this reduces the time for this phase from
11.8 seconds to 1.4 seconds.
Depending on the execution, some accesses to lock could cause NPE.
The best solution we've found so far is to make lock volatile, so that
reads between lock and value are consistent between threads.
It requires further work to determine if we can have one volatile field.
When the other thread has already computed the value and cleared the
lock, the other thread could still enter the computeValueWithoutLock()
and see lock == null
'@ReplaceWith' is not that flexible in this case and proper IDE support
required for smooth migration. After such migration in IDE will be added
- deprecation should be restored.
^KT-54399 Fixed
This very simple interner mechanism ensures that when import runs
within the IDE process, we de-duplicate existing file instances.
This might have an effect, because during GradleProjectResolution
we could have plenty source sets that refer to the same
files.
^KT-55492 Verification Pending
The binary dependency resolver shall only run for remote
artifacts. Project to project dependencies shall be handled
by the IdeJvmAndAndroidSourceDependencyResolver
^KT-55475 Verification Pending
Abduqodiri Qurbonzoda