From `ConcurrentMap#compute`
>The entire method invocation is performed atomically.
>Some attempted update operations on this map by other threads may
>be blocked while computation is in progress, so the computation
>should be short and simple
And we can call resolution (`reanalyze()`) under this synchronized
block that can take unpredictable time.
This fix drops all heavy operations from synchronization
The following updates in the JVM/IR plugin were made:
* Lots of refactoring with preparation for K/N support: commonization of transformations.
* Improved error handling (checks for visibility constraints, appending message about usage constraints in case of an error).
* Explicit requirements for the visibility of atomic properties: to prevent leaking they should be private/internal or be members of private/internal classes.
* Fixed visibility of generated properties: volatile properties are always private and atomic updaters have the same visibility as the original atomic property.
* Volatile fields are generated from scratch and original atomic properties are removed.
* Delegated properties support is fixed (only declaration in the same scope is allowed).
* Non-inline atomic extensions are forbidden.
* For top-level atomics: only one wrapper class per file (with corresponding visibility) is generated.
* Bug fixes.
The corresponding tickets:
https://github.com/Kotlin/kotlinx-atomicfu/issues/322
KT-60528
Merge-request: KT-MR-10579
Merged-by: Maria Sokolova <maria.sokolova@jetbrains.com>
In early prototypes of interpreter, it was easier to assume that
all classes from Java can be interpreted and fix something if not.
Check for Java declaration was done by checking that the package name is
starting with "java". But this is actually wrong and can lead to errors
when some code is declared in "java" something package, but is not from
Java stdlib.
#KT-60467 Fixed
A new resolution diagnostic UnsuccessfulCallableReferenceAtom is
introduced that is used in EagerResolveOfCallableReferences.
No diagnostic is reported on unresolved calls with this diagnostic
because
#KT-59856
Previously, when no file annotations were present, the FIR element
didn't have a source.
By making it nullable, it will only be created when appropriate and the
source will never be null.
#KT-55835
We cannot always return null, because in such case some expressions
would become not fully explorable from the types perspective (see
the documentation on the `getCorrespondingTypeIfPossible`)
`FirNamedReference` might appear when resolving method references (like
`foo::bar`), but also when IJ Platform tries to resolve other parts of
the Kotlin PSI, notably a `KtNameReferenceExpression` in a
function call (`bar` in `foo.bar(baz)` expression).
N.B. FE10 implementation does not support returning `null` as a type -
currently it always returns `Unit` type in case it cannot figure out
the actual type. This issue should probably be tackled together with
KT-60166, so that both implementations are more or less aligned
^KT-60341 Fixed
^KT-59077 Fixed
^KTIJ-25745 Fixed
This test was incorrect as it configured JVM toolchain to use JDK 1.8.
This configured JVM toolchain forced kapt tasks to always use JDK 1.8
even if the build itself was running on different JDK versions. Now test
uses different values for JVM toolchain which should correctly
configure kapt JDK.
^KT-59588
Sergej Jaskiewicz