When we check Java field for constant initializer, we could
be asked to get and check the type of Kotlin's property that
is used in this Java field. But there is no guarantee that the type
resolve phase was finished and this type is available. So we just
check for `const` modifier and skip type check.
#KT-63752 Fixed
#KT-62558 Obsolete
#KT-61786 Declined
This fixes a false negative NO_ELSE_IN_WHEN in K2 and incidentally
also fixes a false positive NO_ELSE_IN_WHEN in K1 since the fix is in
the common code.
#KT-62491 Fixed
Local classes and anonymous objects are normal classes and
kotlin-reflect can load all declarations and modifiers from them, and
support calling members, exactly in the same way as it does for normal
non-local classes.
#KT-41373 In Progress
When an annotation constructor value parameter is annotated with the
very same annotation, FIR2IR went in an infinite loop when trying
to generate it.
To fix this, the constructor is added to the Fir2IrDeclarationStorage
cache before generating the value parameters.
To accommodate for the missing parameters, the value arguments count
is determined using the FIR.
- This change is a prerequisite for allowing combined Java symbol
providers (in LL FIR) to correctly disambiguate classpath order after
getting classes with a combined scope, as the index access of the
combined Java symbol provider is not guaranteed to return the class
that should be first based on the original dependency order. To be
able to disambiguate, a combined Java symbol provider needs access to
all class candidates the index can find.
- `FirJavaFacade.knownClassNamesInPackage` cannot be computed in the IDE
using the current strategy because there are multiple finders and
there is no `CliFinder`. However, the cache was still used, which
caused it to be filled with `null` values and additionally caused
worse performance in `JavaSymbolProvider` due to hash map accesses via
`hasTopLevelClassOf`.
- Rewriting the strategy is non-trivial as additional indices are needed
on the IDE side. See KTIJ-24642.
When suspend function type is serialized, there is special logic that
adds Continuation parameter, before doing so, type-aliases has to be
expanded, attributes for resulting type should also derive from
expanded type
KT-53193, KT-54062
In DeserializedClassDescriptor and MemberDeserializer, only the
`contextReceiverTypeList` field was used, and not
`contextReceiverTypeIdList` which is used when `-Xuse-type-table` is
enabled. The convention is to use a bunch of utilities declared in
`protoTypeTableUtil.kt` which deal with both methods of reading types.
Also, simplify the deserialization code in FIR (which was correct for
some reason).
But still compile stdlib, reflect, kotlin.test and scripting runtimes
with JVM target 1.6 to simplify migration from Kotlin 1.6 to 1.7.
#KT-45165 Fixed
This is a partial revert of e857966edb.
Specifically, behavior is restored in the old backend, which will allow
to support language version 1.3, where this language feature was not
enabled yet. There are no changes in the JVM IR backend, because to
enable JVM IR with LV 1.3, you need to pass the compiler argument
`-Xuse-ir` which is not stable and we don't guarantee anything about it.
#KT-50251
In KT-50198, Spock generates a method named `$spock_feature_0_0` which
is annotated with `org.spockframework.runtime.model.FeatureMetadata`.
The problem is that for some reason (probably a bug in Spock or some
kind of version mismatch), this annotation lacks value for the method
`dataVariableNames`, which has no default value.
If an annotation lacks a non-default value, it's OK for the JVM, but not
OK for Java reflection. Specifically, `Annotation.equals` for annotation
proxy classes created at runtime checks that values are equal for each
annotation method. If there's no value for some annotation method
without a default value, it fails with NPE.
kotlin-reflect used `Annotation.equals` in `ReflectJavaAnnotation`,
however there was no intention to perform structural equals on
annotations; equals/hashCode were implemented only to make stuff like
`LazyJavaAnnotations.annotationDescriptors` work, which is a hash map
where `JavaAnnotation` (`ReflectJavaAnnotation` in kotlin-reflect) is
the key.
This commit changes equals/hashCode to use identity instead, since this
is cheaper, and safer because of cases like the one described above.
This is also consistent with other implementations, e.g. PSI-based
`JavaAnnotationImpl` which naturally checks if the underlying PSI
elements are the same, without any kind of structural equality.
I'm not entirely sure why this appeared as a regression in 1.5.30, but
the most likely candidate is the signature enhancement refactoring,
after which we (supposedly) started to load more annotations on
declarations coming from Java, just in case they are annotated with some
nullability annotations.
No test added because to replicate the issue, we basically need to
generate an incorrect annotation proxy class _at runtime_, which is
difficult.
#KT-50198 Fixed
Since IDEA moved most of it's jars to java 11 it's illegal to use them
in our dependencies, so all modules which use `intellijDep()` should
carefully specify which jars they use
We are working on a feature in the Kotlin Gradle plugin called
`kotlin.incremental.useClasspathSnapshot` to improve incremental
Kotlin compilation.
To allow reuse when writing this feature, this commit moves most of the
code in RuntimeModuleData (in the ':core:descriptors.runtime' project)
to DeserializationComponentsForJava (in the ':core:descriptors.jvm'
project), so that the API can be accessed from the
':kotlin-gradle-plugin' and ':kotlin-build-common' projects where the
feature is written.
Bug: KT-45777
Test: Existing tests should pass (this is a refactoring-only change)
We are working on a feature in the Kotlin Gradle plugin called
`kotlin.incremental.useClasspathSnapshot` to improve incremental
Kotlin compilation.
In this feature, we need to extract ABI information from a .class file.
If the .class file is a Kotlin class, this info can be found in the
class header data. But if the .class file is a Java class, this info is
not readily available.
The RuntimeModuleData class in the ':core:descriptors.runtime' project
can help with that: It uses reflection to generate `ClassDescriptor`s.
However, reflection requires a full classpath to work correctly, whereas
we want to generate a `ClassDescriptor` directly for each class file
(also, reflection is probably slow).
To address that, this commit refactors RuntimeModuleData so that it can
support a generic Kotlin/JavaClassFinder, which can be based on either
reflection or bytecode analysis. The existing code continues to use
reflection while the new feature will use bytecode analysis (e.g., using
the existing BinaryJavaClass).
Bug: KT-45777
Test: Existing tests should pass (this is a refactoring-only change)
There seems to be no point in configuring the compiler argument per
project. This argument will be deleted soon anyway, when we remove
support for JDK 1.6 & 1.7.
Also remove `disableDeprecatedJvmTargetWarning`. It didn't have any
effect in all modules where it was applied because these modules
reassign `freeCompilerArgs` anyway, with
`-Xsuppress-deprecated-jvm-target-warning` in it.
Dmitriy Novozhilov