Currently, KAPT3 uses JDK internal API to build Java AST.
Since the API is internal, it has changed in newer JDKs.
So, for them, use reflection to access new API.
#KT-59349 Fixed
This change expanded KAPT to support a new param
'fileAccessHistoryReportFile', which reports all the classes used during
annotation processing into a file, in the form of a list of URIs.
This is useful for build speed improvements described in https://engineering.fb.com/2017/11/09/android/rethinking-android-app-compilation-with-buck/.
Essentially, using the list of used classes, we can compile only
the dependencies that are really affected by the developer's
code changes and improve Kotlin build speed.
^KT-52853
To check that boolean "is" prefix is treated correctly, and Unit return
type is not translated to void. `@Deprecated` annotations are added just
so that the `$annotations` methods would also be generated.
In normal circumstances, it leads to the field `c$delegate` NOT being
generated (see KT-39054). However, it's not the case in kapt in any
mode:
- In the old JVM backend, this optimization is not supported.
- In JVM IR, property initializers are missing in light analysis, so
backend cannot figure out that this property is optimizable.
- In kapt4, backend is not being run, and symbol light classes do not
have information about this optimization.
Overall it doesn't matter much which stub is generated here because the
field is private, the test is added just in case.
Also adds rendering of @Metadata annotations in Kapt3 and Kapt4 tests
(currently disabled for a few tests).
Co-authored-by: Alexander Udalov <alexander.udalov@jetbrains.com>
This commit includes the basic Java stubs generation infrastructure and
the corresponding tests. The main entry point is called
Kapt4StubGenerator. Calls to it from production code will be added in a
separate commit.
#KT-51982
- make some utility functions and classes public
- split some classes into common and Kapt 3 - specific parts
- use Kapt 4-ready filtering of @Metadata annotations in tests
Problem is reproducible only when singing is enabled.
Register dependencies between publication and signing tasks.
It looks like signing tasks have same output and need to be registered
in all publications.
Error:
* What went wrong:
Some problems were found with the configuration of task ':kotlin-annotation-processing-embeddable:publishMainPublicationToMavenLocal' (type 'PublishToMavenLocal').
- Gradle detected a problem with the following location: '/Users/Shared/Projects/kotlin/plugins/kapt3/kotlin-annotation-processing-embeddable/build/libs/kotlin-annotation-processing-embeddable-1.9.255-SNAPSHOT-sources.jar.asc'.
Reason: Task ':kotlin-annotation-processing-embeddable:publishMainPublicationToMavenLocal' uses this output of task ':kotlin-annotation-processing-embeddable:signGradleCompatPublication' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
Reproduce:
gradle :kotlin-annotation-processing-embeddable:publishToMavenLocal -Psigning.gnupg.keyName=* -Psigning.gnupg.passphrase=* -PsigningRequired=true
KTI-1282
This is needed in order to run light analysis mode tests for JVM IR
backend. In the subsequent commit, this extension is added to light
analysis mode tests.
Kapt stub generation uses this extension to transform local types to
non-local:
private val x = object {}
With this extension, x's type will be `Any`. Without it, it will be an
anonymous type. This anonymous type was not a problem for the old JVM
backend, but it's difficult to translate it in the IR infrastructure in
the light analysis mode where bodies are not resolved.
When kapt stub generation works with JVM IR enabled,
KaptAnonymousTypeTransformer ensured that backend would not crash and
stubs would contain something useful.
However, this is not happening in light analysis mode tests, which are
supposed to check how compiler behaves in the light analysis mode which
is used in kapt.
In kapt stub generation mode, psi2ir does not generate bodies of
declarations. This means that the delegate type was translated into an
IrType which is based on a class which is not generated by psi2ir, thus
leading to an unbound symbol error. The fix is to avoid using anonymous
types for delegate fields in this mode.
#KT-59211 Fixed
Still supported IDEA/Kotlin plugin releases relies on
'kotlin-annotation-processing-gradle' artifact name in compiler plugins
classpath. I've restored this publication usage until we will stop
support Kotlin plugin versions that doesn't know about
'kotlin-annotation-processing-embeddable' name.
^KTIJ-25586 Fixed
The code in IrTypeMapper was incorrectly translated from
KotlinTypeMapper during the development of JVM IR. The
`classDescriptor.hasBigArity` condition in KotlinTypeMapper was checking
if the class represents a function or a suspend function with big arity,
and the suspend function part was lost during conversion.
This resulted in incorrect generic signature being generated, which led
to malformed type exceptions from reflection, and compilation errors
from kapt stub generation.
Also, change a comment in irCodegenUtils to avoid confusion of numbered
function types (kotlin.jvm.functions.Function1, ...) with the big-arity
type kotlin.jvm.functions.FunctionN.
#KT-58375 Fixed
The tests are removed because JvmDefault is going to be deprecated with
error in KT-54746 and removed later in KT-57696.
Many of the removed tests already had existing counterparts with the new
modes `all` and `all-compatibility`. In this change, I've added such
tests where they were missing, and removed tests which were testing
behavior specific to the JvmDefault annotation, such as some
diagnostics.
#KT-54746
Generate a declaration for each delegated member without body. If we
don't generate delegated declarations, subclasses will have incorrect IR
with unbound symbols in fake overrides.
#KT-58027 Fixed
- removed 'kotlin-annotation-processing-gradle' publication as it
duplicated 'kotlin-annotation-processing-embeddable'
- removed 'kotlin-annotation-processing-maven' as it is embedded into
'kotlin-maven-plugin'. Instead 'kotlin-maven-plugin' now depends on
'kotlin-annotation-processing' directly.
^KT-52811 In Progress
This change allows to revert adding `WITH_STDLIB` directive
to tests which happened at `a9343aeb`.
Co-authored-by: Alexander Udalov <Alexander.Udalov@jetbrains.com>
This inconsistency is present due to not using the `// WITH_STDLIB`
in the above tests. When K1 creates the enum, it tries to generate
`entries()`, and for that it tries to load `kotlin.enums.EnumEntries`,
but this is actually an unresolved reference. K1 silently swallows it,
and proceeds.
The reason K2 doesn't fail is that in order to generate `entries()` it
simply creates the necessary `ConeClassLikeType` with the desired
`classId` instead of loading the whole `ClassDescriptor`.
The reason we can still observe `$ENTRIES` and `$entries` in K1
is because they are generated during the JVM codegen, and it
only checks if the `EnumEntries` language feature is supported. It
doesn't check if the `entries` property has really existed in IR
(by this time it's expected to have already been lowered to the
`get-entries` function - that's why "has ... existed").
The reason why the codegen doesn't fail when working with
`kotlin.enums.EnumEntries` is because it creates its
own `IrClassSymbol`.
^KT-55840 Fixed
Merge-request: KT-MR-8727
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
Apparently it depended on the ordering of the synthetic `$annotations`
methods generated for properties. And those methods were always
generated at the end of a Java stub by kapt because they lacked PSI
element, and thus `ClassFileToSourceStubConverter.convertClass` could
not compute their source position, and it placed them at the end as all
other synthetic methods.
The solution is to provide PSI element for `$annotations` methods in
JvmDeclarationOrigin. This origin is then collected in kapt in
`OriginCollectingClassBuilderFactory` and used for sorting, as in the
case of the old JVM backend.
#KT-56360 Fixed
Ivan Kochurkin