Platform is trying to modify the class inheritance list during intension (see the test name above) action process but it cause a cross-language changes via PSI.
To make this possible LightClasses are supports this behaviour with a little support of it (inheritance list Add and inheritance list element Delete are supported).
It need's to be done for UL-classes in same way.
Two known issues with generateNonPartClassDeclarations that was here
before were the fact that we didn't sort sealed classes and its
subclasses which led to NoSuchMethodError (KT-27097), and the fact that
we didn't skip expect classes which led to incorrect duplicate JVM class
name diagnostic (KT-30843)
#KT-27097 Fixed
#KT-30843 Fixed
This was broken in c1ab08c8ce where we started to represent KClassValue
as a ClassId of the referenced class + number of times it's been wrapped
into kotlin.Array. Local classes do not have a sane ClassId, so in this
change we restore the old behavior by representing KClassValue with a
sealed class value instead
#KT-29891 Fixed
Before this commit, we used script context for all classes
defined in script. However, for local classes in scripts it's mistake,
and now we generate them as usual, despite of the fact we are in script.
#KT-28997 Fixed
It helps to generate properly the annotations for delegates
Also note in test, that annotations in Base class have really weird
text of arguments and also don't have names
Mostly, it's needed for clarity and to simplify
what exactly `kotlinOrigin` means in each case:
- Note, that annotatedOrigin() is always kotlinOrigin
- We don't need to store another field for receiver
- Now, kotlinOrigin is consistent with KtLightParameter::kotlinOrigin
KtLightNullabilityAnnotation is specifically designed for old light classes
and includes a bunch of hacks that are applicable for them
So, we have to introduce own hack into it
(see org.jetbrains.kotlin.asJava.classes.KtUltraLightParameter#getTypeForNullability)
that is a bit of hard to support when extending hierarchy
When making KtLightNullabilityAnnotation after test org.jetbrains.kotlin.idea.caches.resolve.IdeLightClassTestGenerated.NullabilityAnnotations#testJvmOverloads
started failing the wrong assumption was made that for
@JvmOverloads-generated overloads their last parameter is always nullable
(see removed isNullableInJvmOverloads function) and that lead to a bug,
namely KT-28556.
The actual problem of this test started failing was incorrect definition
of kotlinOrigin in KtLightParameter for case of JvmOverloads:
wrong KtParameter was being chosen before
This commit fixes the issue by propagating how actually generated
parameters in codegen relate to source KtParameters'
^KT-28556 Fixed
It's gonna be used in the later commits
Also simplify a bit related code in `_type` initializer:
it seems safe just to map `kotlinType` as is for all non-trivial cases,
also note that all of them are actually generated without generic signature
There's no need to add "values"/"valueOf" methods for them
(see com.intellij.psi.impl.compiled.StubBuildingVisitor#visitMethod that ignores them too)
We already have tests that check enum entries/synthetic methods
are properly resolved in Java:
idea/testData/kotlinAndJavaChecker/javaAgainstKotlin/*Enum*
Igor Yakovlev