Fix REPORT_OUTPUT_FILES option passing to GenerationState created in kapt.
This fixes these tests:
Kapt3Incremental.testChangeAnnotatedPropertyType()
Kapt3Incremental.testRemoveAnnotations()
Kapt3Incremental.testRemoveSourceFile()
Appears that plugin classpath can contain not only `File.separatorChar`, but also '/' on Windows. Without the proper handling of this case, Gradle importer may import the plugin JAR made for Gradle with shaded 'com.intellij' and cause an exception during the JPS build.
Allow to run kapt in "annotation processing only" and "stub generation only" modes in order to support incremental compilation in Gradle.
Unfortunately, annotation processing can't be done incrementally cause it uses all module files, but the stub generation can be done incrementally.
Allow to get annotation list and to invoke `findAnnotation` without building delegate
Introduce KtLightNullabilityAnnotation which holds nullability information and is built
before delegate is built
This makes "-verbose" not required for JPS to run correctly and
therefore allows to print more useful debugging stuff in the compiler
and read them in CLI, for example. The output will also be more readable
because there'll be no "output" messages
Kapt3 won't work without the 'tools.jar' file provided, but we shouldn't throw an exception in this case.
This commit adds the warning message (and disables Kapt if it can't be used).
"kapt.kotlin.generated" AP option is always present (and it's the way to say the arbitrary processors about the target directory for generated Kotlin source files).
In this commit, the "fake" empty annotation processor is added to consume the option if no other processor does it.
rename source-sections compiler plugin jar in the dist (add kotlin- prefix),
according to the agreed naming scheme for the artefacts. (The renaming of the
other plugins should follow.)
in addition configure proguard to retain VirtualFile members, since they
are used in the source-sections plugin
Class APIs from java point of view stays the same so we can avoid generating those methods
Otherwise we have to calculate all supertypes when getMethods() is called,
which imposes severe performance penalties
We have to pretend these methods are not 'abstract' (also we consider them 'default' for safety)
so java highlighting does not report "class should be abstract" for all inheritors
We have to manually report "class should be abstract" on some of the java inheritors,
specifically those that are implementing interfaces directly
as opposed to extending kotlin classes implementing those interfaces
Yan Zhulanow