- Rewrite `TestModule.publishModificationEventByDirective`: we can get
the `KtModule` to publish an event for via the test module. The
directive can now be made optional, which is necessary when we want to
specify it in potentially multiple modules.
- Introduce the `WILDCARD_MODIFICATION_EVENT` directive, which allows
specifying THAT some modification event should be raised for a module,
but not WHICH one. This allows generating multiple tests which raise
different modification events over the same test data.
- Add various convenience functions for publishing wildcard modification
events. `publishWildcardModificationEventsByDirective` for the test
module structure is quite opinionated, but takes a lot of work from
test implementations.
- Because `ModificationEventDirectives` are part of the analysis test
framework, we register them as a general Analysis API test directive.
^KT-56288
- The non-concurrent `CleanableSoftValueCacheTest` ensures that
deterministic cleanup behaves correctly. A Lincheck test can only
discover differences between the single-threaded and concurrent
executions of a test scenario, so it cannot find correctness issues
with deterministic cleanup on its own.
^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
- 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
- `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
- `TestModule.explicitTestModuleKind` requires a directive to be present
to get the `TestModuleKind`. But we still want to find out the test
module kind for test modules without a directive. Hence, we have to
add this property to `KtTestModule` during its construction.
^KT-65960
- `KtModuleWithFiles` isn't actually used in a production Standalone API
context, but it was exposed via `analysis-api-standalone-base`. In
current production usages, the project structure is built with the
module builder DSL.
- Hence, `KtModuleWithFiles` is only relevant for tests. This commit
moves `KtModuleWithFiles` to the Analysis API test framework and
renames it to `KtTestModule`. This removes any risk that an outside
user could start using `KtModuleWithFiles` and completely uncouples
the test project structure from production APIs.
- In addition, we can add the `TestModule` to `KtTestModule`, allowing
tests to quickly access the original test module, for example to check
the test module kind.
- The commit also removes the data class status of `KtTestModule` and
`KtTestModuleProjectStructure` to avoid issues with destructuring when
properties are added or removed.
^KT-65960
- The configuration allows the test infrastructure to decide whether to
index binary libraries to stubs (when stub-based deserialized symbol
providers are used) or to skip indexing (when class file-based
deserialization is used).
- The information is needed in `AnalysisApiBaseTestServiceRegistrar`,
where the `KotlinStaticDeclarationProviderFactory` is created. This
service registrar shouldn't access `LLFirLibrarySymbolProviderFactory`
and so checking the library symbol provider factory wasn't an option.
- Another alternative was adding a property to
`AnalysisApiTestConfigurator`. However, this then requires passing the
property to `AnalysisApiBaseTestServiceRegistrar`, because it doesn't
have access to the configurator out of the box. This however goes
against the design of our service registrars, which generally only
access test services. So adding a test service seemed like the best
solution.
^KT-65960
This commit adds code to check whether a deserialized cone type is a
special function type kind or not when resolving the type of a lambda
expression (anonymous function). If it is a special function kind, it
sets the type of lambda based on the special function kind.
^KT-64994 Fixed
The test infrastructure for analysis supports binary module tests, but
the binary build does not use another binary module as a dependency when
it passes the class path. As a result, each binary module build does not
work when they have dependency on each other.
This commit fixes the issue by
1. Topological sort in the order of dependency graph for test modules.
2. Pass module paths as extra class paths when they have dependency on
each other.
^KT-64994
Previously, the code was calling into
TopDownAnalyzerFacadeForJVM.newModuleSearchScope, which includes
AllJavaSourcesInProjectScope.
This lead to .java-sources being incorrectly attributed to wrong
modules in tests, which, in turn, could've introduced undesired
behaviour around module-dependent checks (e.g. whether a variable
is from the other module and thus can't be smartcasted)
Render caret names in resolve testData, so that we don't have to guess
the indices of the carets;
it makes the multi-caret testData less error-prone.
Relevant for KT-65152 and KT-62695
Add possibility to `ExpressionMarkerProvider` to get all the carets
from the file.
Use it in `AbstractReferenceResolveTest`, but not check all the carets
yet.
Required for KT-65152 and KT-62695
There are three test entry points:
* [doTestByMainFile] – test cases with dedicated main file.
Supports everything from single-file cases to multi-platform multi-module
multi-file cases
* [doTestByMainModuleAndOptionalMainFile] – test cases rather around
modules than files
* [doTestByModuleStructure] – all other cases with fully custom logic
Look at the KDoc of the corresponding method for more details.
^KT-64805 Fixed
- `TestModuleStructureFactory.createProjectStructureByTestStructure`
created `KtModule`s for each test module and then also created new
`KtModule`s for binary dependencies. This split worked as long as no
binary dependency was also a test module and thus part of the main
modules. But if not, `addLibraryDependencies` created a duplicate
`KtModule`, instead of referring to the existing binary module.
- The fix registers a main binary library module in the library cache
before it can become the dependency of another main module. Because
main modules can only depend on main modules preceding them in the
list, a separate pass over all main modules is not needed.
^KT-64647 fixed
In the 'IGNORE_SELF' mode, dangling files don't have their own
declarations in providers. As a result, all references there resolve to
declarations of the original file. It is conceptually similar to that we
had in on-air resolve, however, now it's possible to work with the whole
content of the in-memory 'FirFile'.
As it can be seen in 'ProjectStructureProvider.kt'
(KtFile.danglingFileResolutionMode), the 'IGNORE_SELF' mode is
automatically applied for non-physical files with an original file being
set. For other scenarios, now there is a new 'analyzeCopy()' function
that allows to pass the analysis mode explicitly.
The previous implementation in 'TestModuleStructureFactory' had very
custom and redundant logic for binary dependency collection.
In particular, JDK and kotlin-stdlib were specifically computed,
although both already were in the module classpath, which was handled in
'createLibrariesByCompilerConfigurators()'. In addition, there was no
support for common modules.
The new behavior is much closer to what happens in production.
Previously we just skipped Java sources.
The order of classes in light classes test data is changed due to
differences in implementations of `compileLibraryToJar` and `runJvmCompiler`
^KT-62892
As it is more similar to production. Also, fixed scope search for klib.
Now we register main binary modules before to avoid duplication with
libraries from createLibrariesByCompilerConfigurators as now we can
have a declared library and regular sources
^KT-62888
^KT-62651
Mikhail Glukhikh