e.g. if ast is loaded then no stub is attached to a file
but building deserialized fir can require information from enriched cls stub,
otherwise part of the information would be missed, e.g. contracts.
presumably, this can happen only after decompiled code is opened in the editor
(also meaning no source code is attached to the library),
green stub should exist until GCed,
thus performance degradation in the common case is not expected
Because the overload has a meaningful implementation only in JVM.
In other platforms the specified lock object is ignored.
In K/N it throws UnsupportedOperationException.
Use a newer version of the compiler with changes to archive name
(contains arch). Also, remove obsolete test for the old version.
Merge-request: KT-MR-10399
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
Apparently users are using these constants in their build script
configurations. Until we will provide proper public API we should keep
such constants as public.
^KT-58916 Fixed
If the found index is odd, retry search from index + 1.
Merge-request: KT-MR-10364
Merged-by: Abduqodiri Qurbonzoda <abduqodiri.qurbonzoda@jetbrains.com>
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.
Fixes #KT-58918
If the serializable class contains itself as a generic parameter of the property, and its serializer is not an object (for example, for a sealed class), in this case there is a race in the initialization of the serializer and child serializers.
Merge-request: KT-MR-10363
Merged-by: Sergey Shanshin <Sergey.Shanshin@jetbrains.com>
According to
`FirNativeCodegenBoxTestGenerated.testNestedClassesInAnnotations`,
the annotation
`kotlin.internal.PlatformDependent` is
unresolved reference.
^KT-58549 Fixed
- Due to KTIJ-25562, combined stub-based deserialized symbol providers
currently create code correctness issues and should thus not be
enabled.
- Once that issue is fixed, KT-58325 should be revisited.
- `dependency2` is needed to ensure the creation of combined Kotlin
symbol providers. If there is only a single dependency Kotlin symbol
provider, the combined symbol provider won't be created.
- To test the reference resolution of declarations provided through
resolve extensions of module dependencies, we need support for
multimodule resolve extension tests.
- A proper merging strategy for declaration providers is required for
cases where the main declaration provider created by
`createDeclarationProvider` can't provide all declarations that the
original declaration providers can provide. Then, only a sublist of
the declaration providers should be merged, while keeping the
unmergeable declaration providers intact.
^KT-58580 fixed
- `KtNotUnderContentRootModuleForTest.directRegularDependencies` is
called during project structure creation, which led to builtins
session creation during that period. This in turn led to the creation
of `JvmStubBasedFirDeserializedSymbolProvider`, which failed upon the
initialization of `declarationProvider` because
`KotlinDeclarationProviderFactory` wasn't registered yet. This is
precisely why `declarationProvider` was made lazy.
- However, with the new `FirSymbolNamesProvider`, keeping
`declarationProvider` lazy is harder, because `symbolNamesProvider`
(if also made lazy) is requested during composite symbol provider
creation in `createBuiltinsAndCloneableSession`.
- The solution avoids creating the builtins session entirely. Instead,
`directRegularDependencies` now gets the `KtBuiltinsModule` directly,
which is more straight-forward as well.
- An LL FIR test failed after merging stub-based deserialized symbol
providers into combined Kotlin symbol providers:
`DiagnosticCompilerTestFE10TestdataTestGenerated.TestsWithStdLib.Multiplatform.testJvmOverloads`
- Cause: The combined Kotlin symbol provider was able to find a class
for `JvmOverloads`. However, the `KtModule` of `JvmOverloads` was
`LibraryByRoots` with just the stdlib, while the registered stub-based
deserialized symbol provider was known to the combined symbol provider
with a `LibraryByRoots` containing 6 different paths. Hence, the
single-root module wasn't found in the provider map.
- The fix creates a `LibraryByRoot` for each root, which leads to a
separate deserialized symbol provider for each of the six roots,
solving the discoverability problem.
Artem Kobzar