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
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
In particular, JVM IR doesn't provide KtFile for a multifile facade in
JvmDeclarationOrigin (JVM backend provides KtFile of a random multifile
part). This led to multifile classes being completely ignored in the
JVM_IR version of kapt. Now they are generated correctly and the changed
test passes, but there's a _ir.txt expectation file because the order of
'foo' and 'bar' is different (which is not a problem).
This is a hack to implement KT-32596 in the JVM IR version of kapt.
Basically we allow psi2ir to generate annotations whose classifier is
error class, which happens when it's unresolved. Because there's no
physical IR for an error class, we create stub IR for it via
SyntheticDeclarationsGenerator in case we'll need it.
With this hack, annotations with unresolved classifiers magically
survive all the way until the codegen (with a minor change in
IrBasedDescriptors) where they are generated as
`@error.NonExistentClass`, which then gets corrected by the kapt's
"correct error types" mode as in all other cases of error types.
Use the property as PSI element origin for delegated property accessors
and field in JVM IR as it is done in the old JVM backend. Otherwise kapt
"correct error types" mode can't find the property type and thus cannot
succeed in "resolving" it, which led to java.lang.Object being used as a
fallback.
Note that in the unmuted test, .txt and _ir.txt dumps differ only in an
unrelated NotNull annotation on a delegate field.
See also KT-37586 for some related changes which fixed this problem
initially in kapt.
When using correct error types and there is a property setter or
receiver for an unknown type then the parameter type would be `Object` instead
of the error type.
This fixes KT-46965 and KT-46966
Previously the annotations were included in reverse order. With this
change they are kept in the same order as in the source file.
This changes the test case for KT-23427 but that issue seems to relate
to annotation arguments that are missing, not the order of repeatable
annotations.
This fixes KT-51087
Migrate KaptJavaLog to not used deprecated constructor in newer JDKs and instead set up the writers during initialization. This enables us to get rid of KaptJavaLog17.
Fixes KT-54030
Interface methods that were private got both the `default` and `private`
modifiers when using `jvm-default=all` which is not valid.
The stub will now just contain `private` in this case.
This fixes KT-48013.
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).
Alexander Udalov