Previous approach prevented double registration of the plugins, but
might have caused a race condition: atomic flag was set before the
plugins initialization, not after, so another thread could see garbage
data even if it could read the flag set to "true".
This might or might not be a root cause for the KTIJ-24983 exception,
so we'll have to wait for some time before actually closing the issue.
^KT-58985 Fixed
Review: https://jetbrains.team/p/kt/reviews/10385
`isData` returns `true` for `data object`s even if kotlin-reflect
version is old (1.2.0), so it looks like we got correct `KClass.isData`
behaviour for "free". That's why this behaviour was never covered with
tests.
This commit updates the documentation and covers the behaviour described
in the KDoc with tests.
According to
`FirNativeCodegenBoxTestGenerated.testNestedClassesInAnnotations`,
the annotation
`kotlin.internal.PlatformDependent` is
unresolved reference.
^KT-58549 Fixed
- In LL FIR, we have increasingly formalized symbol name caches as
palpable objects. The main reasons for this formalization were the
need to share implementations of caching between different (LL FIR)
symbol providers, the need to build composite name caches from
individual name caches, and the introduction of resolve extensions
which may provide additional declarations and thus complicate the name
set construction for Kotlin symbol providers in LL FIR.
- `LLFirSymbolProviderNameCache` also shared a lot of similarities with
cache handling in FIR providers like
`FirCachingCompositeSymbolProvider` and
`AbstractFirDeserializedSymbolProvider`.
- This commit introduces a `FirSymbolNamesProvider` as a component of
`FirSymbolProvider`. This symbol names provider's task is to provide
the sets of names which `FirSymbolProvider` previously provided. It
also allows sharing implementations of `mayHaveTopLevel*` once and for
all, which is an improvement over the previously scattered
implementations (the same ideas replicated many times throughout
different symbol providers).
- `FirSymbolNamesProvider` by design doesn't cache, as many symbol
providers may not need such a cache. `FirCachedSymbolNamesProvider`
can be used to cache symbol names if needed. The symbol name provider
architecture also makes it easier to switch between caching and
non-caching, without the need to reimplement caches every time.
- Synthetic function types complicate the picture, but this complication
is now exposed with the rest of the API, instead of being hidden in a
few implementations here and there. This allows symbol providers to
more explicitly state whether they can provide generated function
types, which is an advantage for the correctness of composite symbol
providers.
Some specific notes:
- In `FirSyntheticFunctionInterfaceProviderBase`, the class ID check has
been replaced with a full `mayHaveTopLevelClassifier` check so that
the cache doesn't get filled with `null` entries.
- `LLFirKotlinSymbolProviderNameCache` is turned into a non-caching
`LLFirKotlinSymbolNamesProvider` so that this symbol names provider
and those of resolve extensions can be composed into one caching
symbol provider in `LLFirProviderHelper` without creating layers of
caches. If the Kotlin symbol names provider was caching out of the
box, `LLFirProviderHelper.symbolNameCache` would cache the
names (1) in the combined symbol names cache and (2) in the Kotlin
symbol names cache.
- A caching Kotlin symbol names cache can still be created easily with
the `LLFirKotlinSymbolNamesProvider.cached` constructor function.
Nested classes which are not inner class should not be able to access
type parameters of the outer class. Make sure access is not available
when resolving super types.
#KT-54748 Fixed
Cases when default argument inhertied from super class are allowed.
Some tests for default arguments already exist and can be found in
`testData/diagnostics/tests/multiplatform/defaultArguments`, for example
`annotationsViaActualTypeAlias.kt`.
^KT-57614 Fixed
Merge-request: KT-MR-10356
Merged-by: Roman Efremov <Roman.Efremov@jetbrains.com>
When we create `SmartTypePointer` directly inside `JavaSymbolProvider`,
the Java resolution is called which is forbidden inside the
`JavaSymbolProvider`.
Instead, the lazy `JavaElementTypeSource` for JavaType is created,
which creates a `SmartTypePointer` outside `JavaSymbolProvider`.
^KT-58194
This is needed to allow using PSI pointers in IDE in JavaElement.
`JavaElement`s are reused between read actions,
so underlying PSI elements might be invalidated when using hard PSI references
^KT-58194
This doesn't reduce the quality of tests, because the flags are still
printed for declarations themselves. We only omit them in references.
However, this makes the tests more compatible with non-JVM backends
(see KT-58605), because flags of referenced stdlib declarations may
differ among target platforms.
When an annotation constructor value parameter is annotated with the
very same annotation, FIR2IR went in an infinite loop when trying
to generate it.
To fix this, the constructor is added to the Fir2IrDeclarationStorage
cache before generating the value parameters.
To accommodate for the missing parameters, the value arguments count
is determined using the FIR.
"oldJvm*" tests are no longer testing the old JVM backend, so remove
that prefix from them. Also, remove the test "firAgainstOldJvm" because
it is now checking something that cannot NOT work.
The feature was previously enabled unconditionally in K2 which
triggered a bug when an enum has an entry with the same name as itself.
#KT-58897 Fixed
#KT-52774
JvmMappedScope.Signatures became mostly irrelevant and only
"useful" for checking if we really need to have the scope mapped
Now, the check is rewritten according to K1 semantics
^KT-57694 Fixed
This change is both makes code more consistent with K1 version
and fixes some issues introduced by previous changes
Before this fix, the test
FirPsiOldFrontendDiagnosticsTestGenerated$Tests$Modifiers$Const.testKCallable_after
was failing
^KT-57694 In Progress
Earlier, it wasn't really important but after the previous commit
when JvmMappedScope semantics has been changed, we erroneously
started loading `toCharArray` as a member to String because
its jvmDescriptor was computed to "toCharArray()Lkotlin/CharArray",
while hardcoded information that prevents it from loading expect
"toCharArray()[C" there.
^KT-57694 In progress
Previously, the semantic was more-or-less correct for most of the cases
but some corner one, like `sort` in MutableList didn't work properly.
Namely, `sort` should be marked there in a way to forbid to call it
everywhere beside super-calls.
Also, overriding it should be allowed.
Mostly, the logic was re-written to K2 model from K1-related
JvmBuiltInsCustomizer.
^KT-57694 In progress
^KT-57269 Fixed
Complex enum entries (those with bodies) with missing overrides
are covered by an existing checker that checks all types of classes. But
simple enum entries (those without bodies) were not covered and require
a separate checker for missing overrides.
#KT-58637 Fixed
Pavel Mikhailovskii