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.
- 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.
- This enables merging `JvmStubBasedFirDeserializedSymbolProvider`
into `LLFirCombinedKotlinSymbolProvider` automatically.
- Crucially, we have to also allow callable caches to take already found
callables as a context.
- We can also simplify the name cache boilerplate using
`LLFirKotlinSymbolProviderWithNameCache`.
- `LLFirKotlinSymbolProvider` is a shared interface for any symbol
providers that are based on `KotlinDeclarationProvider`.
- `LLFirKotlinSymbolProviderWithNameCache` simplifies symbol provider
implementations which use a `LLFirSymbolProviderNameCache`.
- Note that the domain is not limited to "Kotlin symbol providers",
but I don't want to introduce a general base class like
`LLFirSymbolProviderWithNameCache` without multiple class
inheritance (think Scala traits).
- It would be possible to use delegation instead of such a base class,
but that would require a shared interface for the "package name"
functions, which would require some compiler refactoring as well.
- We can base `LLFirProvider$SymbolProvider` on
`LLFirKotlinSymbolProvider`.
- The callables functions in `LLFirKotlinSymbolProvider` expect
`KtCallableDeclaration`s instead of `KtFile`s. This is the preferred
interface, because callable files are only needed for `LLFirProvider`,
not Kotlin symbol providers in general (such as the stub-based
deserialized symbol provider). This also has the advantage that FIR
files containing only properties won't be built for
`getTopLevelFunctionSymbolsTo` and vice versa.
- `KotlinDeclarationProvider` supports computing the top-level callable
package name set now, so we can propagate it to the symbol name cache
implementation.
- Adds the package name check to `getTopLevelCallableNamesInPackage`
directly, which will likely reduce the size of
`topLevelCallableNamesByPackage`, because it needs to store fewer
empty sets.
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
Ilya Kirillov