`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>
The tests are removed because JvmDefault is going to be deprecated with
error in KT-54746 and removed later in KT-57696.
Many of the removed tests already had existing counterparts with the new
modes `all` and `all-compatibility`. In this change, I've added such
tests where they were missing, and removed tests which were testing
behavior specific to the JvmDefault annotation, such as some
diagnostics.
#KT-54746
Sometimes when running MPP tests we may
observe js-specific modules running with
the jvm-specific fir2ir converter
(probably because the name didn't contain
the JVM affix).
In this example we get 2 variants of `kotlin/toString()`:
one coming from the KLib provider, and the
other coming from the builtins provider.
These are identical deserialized functions.
^KT-57601 Fixed
This fixes a false positive resolution error for callable references
to functions with a type parameter that's annotated with
@OnlyInputTypes.
#KT-57994 Fixed
Value parameters annotations are now handled consistently in
factory functions creating this IrValueParameter instances.
In before, it was handled in several different places, which leads to
being sometimes lost, e.g. in LazyFirSimpleFunction.
This caused original problem in interop checks.
^KT-58099
This is a partial revert of 949a39b80f. In the end it turned out not
necessary to prohibit this case (and perform a breaking change), because
JVM backend was fixed to generate it correctly in d73d3c46e2.
#KT-55307 Declined
#KT-55846 Declined
Reason: Design of js(code) replacement is still in flux.
It would be better to delay deprecation until we converge
to proper solution.
This reverts commit 3566d918d2.
This fixes a FIR-specific issue where a type variable is inferred to
Any instead of dynamic. K1 wasn't affected because of a FIR-specific
condition in ResultTypeResolver.
#KT-57962 Fixed
The changes to the irText test data result in the fact that we
now unconditionally unwrap substitution overrides of delegation targets
whereas before we built an unsubstituted scope of the type we delegate
to. If we delegate to a class A : B<C>, the unsubstituted scope of
A can still contain substitution overrides for inherited generic methods
from B<T> that we didn't unwrap before but do unwrap now.
#KT-57899 Fixed
For CallKind.VariableAccess, the condition when to *skip* resolution of
objects was previously collector.isSuccess. This wasn't strict enough
because collector.isSuccess could be true when the best found candidate
has an applicability like RESOLVED_WITH_LOW_PRIORITY (e.g. from dynamic
scope or annotated with @LowPriorityInOverloadResolution). In these
cases, we do want to resolve objects. To fix this, the condition is
changed to collector.shouldStopResolve which is stricter.
#KT-57960 Fixed
The change is needed for the parallel resolution (^KT-55750), so we can resolve the declaration
under a lock that is specific to this declaration.
Previously, if LL FIR was resolving some FirClass, LL FIR resolved all its children too, and it had no control over what parts of the FIR tree were modified.
The same applied to the designation path, sometimes the classes on the designation path
might be unexpectedly (and without lock) modified.
This commit introduces LLFirResolveTarget, which specifies which exact declarations should be resolved during the lazy resolution of the declaration.
All elements outside the declarations specified for resolve in LLFirResolveTarget, should not be modified.
The logic of lazy transformers is the following:
- Go to target declaration collecting all scopes from the file and containing classes
- Resolve only declarations that are specified by the LLFirResolveTarget, performing the resolve under a separate lock for each declaration
^KT-56543
^KT-57619 Fixed
Enum entries can be used as types in Kotlin (even it's a compilation error)
To use the classifier as a type, we need to find if it's hidden or not.
The deprecations for classes are calculated on COMPILER_REQUIRED_ANNOTATION phase, and that's okay as it goes before the TYPES phase.
For enum entries, the deprecations are calculated on TYPES phase which goes on TYPES phase.
This is incorrect as we cannot jump from lower phase to upper phase
The hack ignores such deprecation search for enum entires.
Test: org.jetbrains.kotlin.analysis.low.level.api.fir.diagnostic.compiler.based.LLFirPreresolvedReversedDiagnosticCompilerFE10TestDataTestGenerated.Tests.testEnumEntryAsType
^KT-57648
^KT-56543
Since we forbid overriding `equals` for
value classes, and value classes may only
implement interfaces, we know everything
about their `equals`, hence we can
guarantee if it always returns `false`
for different value classes.
The problem appeared because not all of the `realOverridden` have been
collected because inside AbstractSerializableListDecorator some of the
scopes returned the same instance as direct overridden and after that
overridden tree traversal stopped without detecting real overrides.
Thus, the modality of intersection for
AbstractSerializableListDecorator::size and MutableSet::size
was incorrectly computed to ABSTRACT
The similar thing is already done at the place where we're obtaining
all overrides.
See https://github.com/JetBrains/kotlin/commit/c80cfb0fdb00323ba9b5e1dd98c5cbd0bfab6b8b#diff-182d90c9b8050557e4e2eb319a84b9a51fd0600c728dd0fce85cf6491c13e16dR152
^KT-57693 Fixed
Meta issue: KT-8575
^KT-58061 Fixed
Review: https://jetbrains.team/p/kt/reviews/9677
This commit fixes an inconsistency between
FirUnsupportedSyntheticCallableReferenceChecker and
UnsupportedSyntheticCallableReferenceChecker
In K1 such properties were not considered synthetic and are called
JavaPropertyDescriptor. That's why we need to do an additional check in
K2 checker, while in K1 we didn't need to do it
Also see the previous commit for more related tests that already was
green without this fix but are related to KT-58061 problem
Review: https://jetbrains.team/p/kt/reviews/9677
I'm going to fix KT-58061 in the next commit. Firstly, let's cover
FirUnsupportedSyntheticCallableReferenceChecker with more tests that
already pass, but are related to KT-58061 problem.
mvicsokolova