1. Kapt resolves runtime classpath during configuration, and because of
that we are unable to setup configurations that already took part in
dependency resolution. To fix that, run Kapt configuration as a separate
step out of the main loop over the variants
2. Old Android projects (< 3.0.0) don't have `api` and `implementation`
configurations. To stay compatible with those, ignore these
configurations being absent during configurations hierarchy setup.
Add default implementations for KotlinTarget and KotlinCompilation
(some of them are used in code added by further commits).
Refactor AbstractKotlinPlugin so that parts of its logic can be easily
applied outside the plugin (needed for MPP plugin later).
The single platform Kotlin plugins having Kotlin compiled along with
Java will now create a KotlinCompilation and a KotlinSourceSet per Java
source set or per Android variant.
The build configuration logic will use KotlinCompilation
objects rather than Java or Android plugin entities.
Subplugins API and implementations are updated to use KotlinCompilation.
(Note: this commit leaves the repository in a non-compilable state as it
leaves some of the old API usages unchanged; they are replaced with new
implementations in further commits where more appropriate)
The new implementation covers the wider interface, and the factory
should now be used not on its own but in a named domain object container
(the API for creating a source set is now provided through the
source sets container rather than the factory, so that source sets are
also properly registered).
Do not call this method the second time in KotlinToJVMBytecodeCompiler
where all KtFile instances are already created; just get only those
files that are in the needed module, which can be determined solely by
the file path.
Also "kotlinize" getKtFiles and rename to createKtFiles
Otherwise the "outputDir" in these tests was treated as relative to the
project root, and starting from 63b4302cea, running these tests resulted
in the "whatever" directory being created in the project root
To be able to use it correctly inside an xml build file where, if the
path is not absolute, it's treated as relative to the build file path
(which is TMP_DIR in several tests of the subsequent commit)
Fix for test data (inlineFunctionInsideInlineClassesBox.kt) is needed
to avoid check about "no inline functions".
This check has two steps: first, names of inline functions from
the metadata are loaded, then these names are checked that they are
presented for physical methods in the classfile.
Because now there are no physical methods in the classfile, we can't pass
the second check, therefore this fix is needed.
#KT-24872 Fixed
The source of testdata change is following commit from the
intellij-community repo:
d2bfe3d14bfa48af585f1faddc9a0c37dc05e724
It changes how Java-resolution resolves constructors:
- before, *any* PsiMethod without type reference was treated as
constructor
- now, PsiMethod without type reference is treated as constructor
only if their *names also match*
In particular, in this test, 'void () {}', surprisingly, doesn't have a
type reference ('void' is parsed as PsiErrorElement:Identifier
expected), its name is '<unnamed>', and its visibility is
'package-private' (!)
Therefore, previously we thought that 'Nameless' has package-private
constructor and were reporting INVISIBLE_MEMBER.
Now we don't see any constructor so we add default constructor, which has
public-visibility -> error is gone.
Note that this change affects behavior only when "red" code is already
present in the project (for "green" code, assumption "method without type
reference is a constructor" is indeed correct).
The source of changes is commit the following commit in
intelllij-community repo:
b2b723fa449b16bb1da8102a5efdc219977fefe0 speedup java class resolve a bit
Eseentially, it makes Java resolve (which Kotlin reuses) accept first
matching candidate from explicit named import, instead of continuing
search.
Hence, behavior in cases where several conflicting imports are present,
has changed: before, reference to such names were unresolved, now it's
candidate from first import (see also test UsageMixed.java in the
intellij-community repo).
Therefore, previously we saw such types as undeclared and reported
MISSING_DEPENDENCY_CLASS on them (assuming they are not present in
classpath); now we see such types as properly resolved, so error is
gone.
Because behavior has changed only in case there already was "red" code,
it is not a BC and we can just accept changes.
Before this commit, expect super-class without constructors did not
provoke SUPERTYPE_NOT_INITIALIZED. However, it should, but only
if sub-type is normal class (not an expect one).
So #KT-24597 Fixed
Sergey Igushkin