The previous implementation used a two-stage process:
1) Processing of declared symbols
2) Analysis and processing of referenced dependency symbols
However, to replicate the exact same order as in K1
those two steps need to be done together.
^KT-64953 Fixed
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
Ilya Goncharov