- These tests simply ensure that a resolve extension is disposed after
any kind of modification event is raised. It's not meant to test
complex scenarios, but rather to detect when resolve extension
disposal isn't invoked *at all*.
- I tried implementing a similar test for resolve extension disposal
after soft reference garbage collection, but the only way to force the
GC to collect soft references is to allocate memory until an
out-of-memory error occurs. That is bad for the test infrastructure,
because it might allocate A LOT of memory (depending on the max heap),
which is problematic for running tests locally. Also, our Kotlin tests
stop on an OOM error altogether (so additional configuration would be
required) and the heap is dumped into a 20GB file (on my machine),
which is again problematic for local test runs.
^KT-61222
- This allows tests to specify which modification event they want to
publish.
- The modification event won't be published automatically. Tests need to
invoke `publishModificationEventByDirective` at the right time.
^KT-56288
- This commit adds the `Disposable` interface to `KtResolveExtension`.
Resolve extensions are disposed after their associated session has
been invalidated, or reclaimed by the GC.
- Example use case: Opening a message bus connection with the lifetime
of the resolve extension.
^KT-61222 fixed
- This commit adds a `Disposable` to `LLFirSession` which lives as long
as the session. For example, session components can now open a message
bus connection that is automatically disposed after the session has
been invalidated or reclaimed.
- Because `LLFirSession`s should still benefit from soft reference-based
automatic reclamation by the GC, we have to use a soft value map with
cleanup in `LLFirSessionCache`. It ensures that the child disposables
are properly disposed even when the session is collected as a soft
value.
- The session cannot be the `Disposable` itself because a valid
disposable reference is needed to call `Disposer.dispose`. When a soft
reference is added to a reference queue (such as the reference queue
employed by the soft value map), its referent is already cleared.
Hence, it's not possible to watch a softly referenced `Disposable`
with a reference queue and also pass it to `Disposer.dispose`. This is
why the `LLFirSessionCleaner` contains a strong reference to the
`disposable`, because that will not keep the `LLFirSession` from being
reclaimed, while keeping the `disposable` alive slightly longer than
the session.
^KT-61222
- This cache implementation is useful for lifecycle management of cached
values when we also want to allow the GC to reclaim those values which
are unused. It ensures that the cleanup is (almost) definitely invoked
at some point after a value has been reclaimed by the GC, and also
invokes the same cleanup operation when the value is removed from the
cache conventionally. This unifies the approach to cleaning up such
elements.
- It would be possible to have the cache ONLY perform cleanup for
references reclaimed by the GC, but this would put the onus on the
consumer to perform the cleanup when an element is removed from the
cache conventionally. That comes with its own pitfalls, such as
requiring the user to handle `clear` correctly, or not forgetting
to perform cleanup with the old value returned by `put`.
- "Almost definitely" because the reference queue won't be processed if
the cache becomes unused at some point. However, this is not an issue
for the current intended use case (session invalidation and disposal)
and can be solved by clearing the cache before it becomes entirely
unused.
- The cache requires read and write actions for certain operations to
simplify the implementation of `clear`.
^KT-61222
This is an addition to d4278250e6. Apparently we still need to produce
a new fake override for each inherited static member, because otherwise
we would try to determine the most specific return type, maximum
visibility, etc, all of which makes no sense for static members.
#KT-66152 Fixed
Unify functions from `JsEnvironmentConfigurator` and
`WasmEnvironmentConfigurator` that do the same logic. Make this logic
also be available for `NativeEnvironmentConfigurator`:
- get*ArtifactSimpleName()
- get*KlibArtifactPath()
- get*KlibOutputDir()
- getAllRecursiveLibrariesFor()
- getAllRecursiveDependenciesFor()
- getAllDependenciesMappingFor()
- getKlibDependencies()
This would allow to have the same logic in one place, and also
reuse it in `IrBackendFacade`s to be implemented for Native.
^KT-65117
Adds new warning diagnostic that checks that selected Xcode version is not higher than latest tested with the current Kotlin version
^KT-62373 Verification Pending
The expected format was Kotlin language version (e.g. `2.0`), however the actual passed values were Kotlin release versions (e.g. `2.0.0`)
^KT-65986 In Progress
This diagnostic is reported in rare situations when
StubTypeForBuilderInference is kept as a parameter type
of for loop or lambda. Before this commit, we had in K1
"Could not load module <error module>" from IrLinker instead.
Related to: KT-52757, KT-53109, KT-63841, KT-64066
#KT-53478 Fixed
All dependencies should be registered before the Backend::associate().
^KT-65429
Merge-request: KT-MR-14616
Merged-by: Evgenii Mazhukin <evgenii.mazhukin@jetbrains.com>
This issue should warn users about possible problems in K2 compiler.
Because in this setup there will be no symbols visibility between
those source set roots as it used to be in K1.
There is an assumption that this case usually appears in the code
generation setup. And users might not experience any problems before.
^KT-64913 Verification Pending
- The module structure for these tests was set up backwards: We should
keep the test module kind of the main module flexible (as it is
configured by test configurators), but keep the module kinds of the
binary libraries fixed.
^KT-65960
^KT-64994
- The name wasn't specific enough.
- Remove default `emptyList()` argument from `CompiledLibraryProvider`
so that passing `dependencyBinaryRoots` isn't missed. (My changes
didn't include it in `KtLibraryBinaryModuleFactoryBase` yet, but it
was actually missed from `KtLibrarySourceModuleFactory` even in the
original commit.)
^KT-65960
^KT-64994
- The test infrastructure already requires test modules to be properly
ordered regarding dependencies, so a module A which is a dependency
for a module B must always be ordered before B. Hence, it makes no
sense to also order modules topologically.
- Reordering modules may cause the resulting `KtTestModule`s to be
out-of-order with the test modules, because the topological order
might be different from the test module order, even if the dependency
relationship already holds in the original order.
`KtTestModuleProjectStructure` requires the same ordering as test
modules to ensure the same order during iteration of `KtTestModule`s.
^KT-65960
^KT-64994
- Since binary libraries don't carry decompiled files anymore, the
static declaration provider doesn't index binary libraries in the
Standalone mode, where we don't use stub-based deserialization. This
led `LLSealedInheritorsProviderFactoryForTests` to fail in Standalone
mode for sealed classes from binary libraries, as this provider is now
populated from the declaration provider's index (see the previous
commit). Luckily, class-based deserialization sets
`sealedInheritorsAttr`, so we can simply use this attribute.
^KT-65960
- Now that binary libraries are decompiled to stubs instead of PSI
files, we cannot collect sealed inheritors from `KtFile`s anymore.
Since all `KtFile`s and binary library stubs are both indexed by the
declaration provider, we can collect inheritors from its index
instead.
- Invalidating all sessions at the end of `prepareSealedClassInheritors`
fixes some improper resolve phases in lazy resolution test data. While
the previous implementation requested an uncached resolve session, it
didn't account for sessions of dependencies still being cached.
^KT-65960
- Instead of indexing binary library declarations from decompiled PSI,
the static declaration provider now builds and indexes stubs. As noted
in KT-65960, this brings IDE mode tests much more in line with
decompiled stubs indexing in the IDE. It should allow us to catch
issues with the stub-based deserialized symbol provider outside of IDE
tests.
- In the Standalone mode, we can skip stub-indexing completely, as we
provide FIR symbols via class-based deserialization. This also extends
to shared binary roots.
^KT-65960 fixed
- `LibraryBinary` should not contain any decompiled files, as we want
FIR symbols in tests to be provided from indexed stubs or class files,
but definitely not from decompiled PSI. This brings `LibraryBinary`
much closer to the behavior of binary libraries in the IDE.
- Some tests may still require access to a decompiled file, for example
when trying to test `getOrBuildFir` for some `KtElement` coming from a
library. This commit introduces `LibraryBinaryDecompiled`, which
does contain decompiled files.
- We don't really need `LibraryBinary` as a main test module kind
anymore, since tests generally want to access some main `KtFile`.
Hence, test configurators for `LibraryBinary` have been turned into
configurators for `LibraryBinaryDecompiled`.
- An alternative would be decompiling files on demand, but this is not
currently feasible because the Standalone API doesn't reconcile stubs
with decompiled PSI, like the IDE does automatically. (For the same
declaration, the stub and the PSI will have a different identity.) As
long as there is no support for this, we'll have to rely on a separate
test module kind.
^KT-65960
Marco Pennekamp