It's expected to partially mimic the behavior of what
previously was called builder inference, but with more clear contracts
(documentation is in progress, though)
See a lot of fixed issues in the later commits with test data,
especially [red-to-green]
^KT-59791 In Progress
`Generate Compiler Tests` configuration is not working properly
because it doesn't include analysis api test generator. It was decided
to keep only one generate configuration for tests.
The test data is used both in ":kotlin-util-klib-abi" and
":native:native.tests" modules. It's better to keep it together with
the test data for other KLIB tests which are also used in more than one
module, i.e. in "compiler/testData/klib/" dir.
IC caches often contain file paths. To make them relocatable, we need
to convert these file paths into relative paths, relative to a base
directory.
- If the file paths are source files, we can use the root project
directory as base.
- If the file paths are class files, we should use the classes
directory as base (before this commit, we used the root project
directory in both cases, that's why we hit KT-58547).
The key changes in this commit include:
- RelocatableFileToPathConverter: converts paths to relative paths
- IncrementalCompilationContext: contains 2 different path converters,
one for source files and one for class files
- SourceToOutputFilesMap: maps source files to class files using the
above path converters
- IncrementalCompilerRunner: creates the path converters based on file
locations
Test: RelocatableFileToPathConverterTest unit test
SourceToOutputFilesMapTest unit test
BuildCacheRelocationIT.testCustomBuildDirectory integration test
^KT-58547 Fixed
This API was inspired by kotlinx.coroutines and shall help
making Kotlin Gradle Plugins 'Future' type more applicable for situations
when the Future is used inside the Configuration Phase
^KT-60158 In Progress
The reason #1 for this feature is that we want to test IdSignatures
generated for declarations. Currently, there is no (easy) way to ensure
that a change in the signature building logic doesn't cause any breaking
changes wrt klibs.
Now, most IdSignatures include hashed mangled names in them, so even if
we catch a regression where the included hash changes, there would be no
way of knowing immediately what caused it, unless we'd also have mangled
names in the expectations.
The reason #2 is to test the manglers themselves. Currently, there are
no tests for them. They heavily duplicate each other, this is already
causing issues (see KT-57427) that would be very hard to catch without
these tests.
^KT-58238 Fixed
Dmitriy Novozhilov