This is needed for cases like dump handlers to register corresponding
checkers, which compares identity of dumps for different configurations,
like `IrTextDumpHandler` and `FirIrDumpIdenticalChecker`
Fix the order of pointers and place logical operators first
#KTIJ-28165 Fixed
Merge-request: KT-MR-14447
Merged-by: Vladimir Dolzhenko <Vladimir.Dolzhenko@jetbrains.com>
Check that a custom Promise declaration is supported for the @AfterTest
annotation functionality in the kotlin.test library
This is a part of the fix for KT-63359
Merge-request: KT-MR-14333
Merged-by: Anton Bannykh <Anton.Bannykh@jetbrains.com>
Developers (me) often forget to remove calls to this debugging
utility. Usually this changes is visible during Code Review but we
shouldn't rely on a sharp eye of a human. It is better to automatically
check it during remote run execution.
With `KlibToolOutput` it's possible to forward the output of each
KLIB tool's command to either system stdout/stderr streams or to
some buffers which then can be read by tests.
^KT-62340
This is an option that allows running the commands that support it
in a special "test mode". The "test mode" means (but not limited to)
that a command may, for example, sort the output which is unsorted
by default, and this way guarantee stable output. This is essentially
helpful for tests, which rely on the command output.
^KT-62340
What's done:
- Reduce the visibility of all entities inside the module to `internal`
or `private`. Only leave `fun main()` as `public` because it's the
single legal entry point.
- Add comments to few classes related to "contents" command that they
should be removed together with the command after 2.0.
- Drop useless `DeclarationHeaderRenderer` interface.
- Rename: KlibToolLinker -> KlibToolIrLinker
^KT-62340
When a declaration with an ObjC annotation is stored in a different
module, the annotation arguments are not resolved by default. This leads
to a bug in the checker. Before attempting to find the objCName, it is
necessary to resolve the annotation first.
#KT-64276
It is possible to add source files to task directly. Especially this is
a very popular case for Android integration. Android variants can
contain any number of extra-source files that should be compiled
together with other android-specific sources.
Android specific sources that come from Android source sets already
compiled together as part of "main" fragment (KT-62508).
With this change this logic is extended to any extra sources
that are added directly to the compile task.
^KT-62508 Verification Pending
Java sources can be produced by the task or can be configured with
task dependencies. Previously sources were included into task directly
now they are properly configured with Kotlin Android Source Set.
^KT-63753 Verification Pending
^KT-65426 Verification Pending
Android projects has a number of build type/flavor specific source set.
These source sets are included into compilation of multiple variants.
In Android compilation model they should be compiled together and they
should see each-others declarations. With Kotlin MPP plugin applied
these android source sets gets associated with Kotlin Source Sets
counter parts. However in Kotlin Multiplatform Source sets have
a semantics about "expect/actual" refinement and with K2 it also got
stricter and visibility is checked. This is not compatible with Android
compilation model thus the solution is to merge Android Source Sets
into one K2 Fragment.
^KT-62508 Verification Pending
Setting sources through compile task is not compatible with
Multiplatform K2 because for such sources no K2 Fragment relations
will be set and compilation will fail.
^KT-63753 Verification Pending
Dmitriy Novozhilov