relax acceptedAnnotations extraction rules for obsolete script template
handling code - the previous variant was failing on the typealias
comparison
also reduce warnings and possible exceptions on some test execution
paths
There are two ways how content roots are registered in compiler configuration
in JVM CLI compiler:
1. Directly from arguments
2. From Module, which build from arguments
And there was a problem that both ways used at the same time in some
circumstances (regular compilation without .xml module file) which
caused duplication of all content roots.
Ideal solution for this problem is removal of Module usages at all,
because it looks like redundant abstraction which just complicate
things, but it's too scary to remove it, because it hove some none
trivial usages inside compiler. So to fix problem with duplicated
roots this commit just removes registration of roots from arguments
if Module is used
When counting .class files, stop once the required number is reached.
Also, implement simple counting logic directly, it is 25% faster than
using File.walk(). The way this information is used is a heuristic, so
reducing computation cost makes sense.
^KT-41456 Fixed
Because incremental KAPT tries to reuse .class files produced by kotlinc
and javac, it should check for their existence before starting
an incremental run. Otherwise, annotation processors that perform type
validation will fail to run.
Current check counts the number of declared types in processed .java
sources, and it makes sure the total number of .class files in compiled
sources dirs is equal or higher. Otherwise, KAPT runs non-incrementally.
Tests: KaptIncrementalWithIsolatingApt.testMissingKotlinOutputForcesNonIncrementalRun
^KT-41456 In Progress
When storing source information needed for type analysis, store
.java file and .class file information separately. This is because
for class files only declared typed is needed.
Tests: updating existing ones
^KT-41456 In Progress
Parameter names of some methods are different in JVM IR, for example
extension receivers of property `$annotations` methods are named
`<this>`, which made the `Name.identifier` call fail. It seems fine to
use the "p + index" name for this instead.
#KT-49682
Behavior differs between JVM and JVM_IR backends here because in JVM,
the class descriptor comes from the frontend, and its modality for enum
is never final. For JVM IR, the class descriptor is based on IrClass,
whose modality is sometimes final for enum, presumably because it's
easier for backends (see `ClassGenerator.getEffectiveModality`).
#KT-49682
Similarly to the other places in the IR backend (e.g. see
`copyValueParametersToStatic` in the same file).
In JVM IR, these names are used for example for receiver parameters of
methods copied to DefaultImpls classes. Since Java stub code generated
by kapt mentions them, it fixes a few issues in tests on kapt + JVM IR
(KT-49682).
All of these have a different order of declarations and/or extra
`@NotNull` annotations on fields, both of which doesn't seem like a
problem.
#KT-49682
Since all anonymous types are approximated to a supertype in kapt, type
mapping doesn't require backend information (mapping of anonymous types
to class names) and can be performed statically, independently from
particular JVM backend internals, via descriptorBasedTypeMapping.
#KT-49682
- Include stdout & stderr dump to the exception message if the Java
command fails
- Support running JVM_IR tests
- Do not print anything to the stdout of the test itself in case it's
successful
#KT-49682
Fixes KT-50992
DeclarationDescriptor.isInlineClass misidentifies inline classes without
constructors. This can happen for the ABI of inline classes with private
constructors.
Ilya Chernikov