This `klibSourceFile` information is deserialized from klibs
to retain the information of the original SourceFile location
of a declaration.
^KT-66271 Fixed
It is now unneeded, and future needs should be possible to
be resolved otherwise.
Removing it will simplify further changes to tree generator,
especially for IR.
This is the first implementation of a control flow graph facade for the
extract function IDE refactoring. The exact contents of
'KtDataFlowExitPointSnapshot' will be refined later.
^KT-65762 Fixed
it is impossible to declare test data with another output yet
as `myScriptFile.test.ll.kts` won't be treated as custom definition as
it requires `test.kts` extension.
^KT-66232 Fixed
^KT-66276
Those only implement base classes, their members are not supposed
to be referenced directly (those sometimes they are).
So unused code in there can be suspicious.
On the other hand, some generated builders are truly unused, so leave
the suppression for them.
- This commit moves all session invalidation tests from the IDE which
are non-cyclic to the Analysis API. Cyclic session invalidation tests
cannot be moved because the Kotlin test infrastructure doesn't support
cyclic module dependencies.
- In fact, these new tests cover more cases, because the IDE tests only
covered global module state and module out-of-block modification
events. Crucially, global source modification events are now
supported, which require libraries to be left alone.
- Module out-of-block modification for libraries is technically
undefined, but the test still checks this behavior. The current
session invalidation implementation behaves the same for any kind of
module-level modification event, so it is possible to publish a module
OOBM event for libraries. If this changes in the future, we can
disable those tests. But for now, it's good that these tests run,
because they will alert us to (accidental) changes to this behavior.
^KT-56288 fixed
^KT-65265 fixed
IR expressions are left out for now, because unlike declarations,
which are mostly created via IrFactory, expressions' constructors are
widely used, and it's hard to replicate the exact signatures of those
constructors with the tree generator.
Therefore, some other approach is expected to be taken when generating
them in the future.
^KT-65773 In Progress
- Allows using those with the incoming IR implementation printer.
- Moves the logic to common tree generator, so other trees can specify
default values in base classes as well, if needed.
^KT-65773 In Progress
instead of inside implementation configuration.
Whether a field is a child element is a core concept of the tree,
not a matter of particular implementation class.
It is especially visible in IR tree, where the base classes implement the
acceptChildren method. It will also be more relevant in the future.
This also aligns the config style between IR and FIR tree generators.
^KT-65773 In Progress
The notion of IR element class being 'semantically leaf' is rather hacky.
Instead, now we only distinguish whether an element has its
implementation class, which is what this notion was actually trying to
represent.
^KT-65773 In Progress
analogous to printFunctionDeclaration.
This decouples the printing logic from handling IR elements' fields,
and makes it easier to directly print arbitrary fields.
- 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
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
- 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
- `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
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
based on the regular compiler tests infrastructure, but adding
directives that can customize the definition from testdata.
So far only default imports and provided properties are supported, but
the infrastructure is easily extendable to other customizations.
Another limitations that provided properties are not supported for
the black box tests - the constructor parameters computing code
should be adapted to support it.
Note: in order to pick up the customized definition, the script files
should have an extension .test.kts
This is needed to reduce the size of generated test files, which started
to exceed default IDE limit
Also update some (mostly old) test utilities to remove exceptions from
java signatures
Marco Pennekamp