`ValueParameterData.hasDefaultValue` is now always equal to the original
value parameter's `declaresDefaultValue` flag, so `ValueParameterData`
usages can be simplified to just `KotlinType`.
The change in signatureEnhancement.kt in 432f581cb2 was incorrect.
Contrary to its name, the removed method `hasDefaultValueInAnnotation`
checked not only if the enhancement annotation has default value (which
is what the removed feature was about), but also if the parameter itself
declares default value. This was mistakenly substituted by just `false`
on line 234. The correct change is to use the `declaresDefaultValue`
flag of the original parameter.
It's kind of weird though that in case there's a nullability annotation
on the whole package (like in KT-48316) type enhancement is being done
on everything, including annotation constructors, whose parameter types
can't have any enhancement information. Maybe this should be improved
independently.
#KT-48316 Fixed
Using `starProjectionType` to enhance `?` is pointless because
1. we explicitly ignore nullability annotations for `?` below;
2. mutability is irrelevant;
3. `starProjectionType` never returns references to other type
parameters due to how the type substitutor works.
Create `JavaClassDescriptor`s for Java classes
Ignore anonymous and synthetic classes
as they can't impact recompilation.
Clean up handling of local and anonymous classes
Bug: KT-45777
Test: New JavaClassDescriptorCreatorTest
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)
The main motivation for this change is that
java.lang.annotation.Repeatable has a parameter for the container
annotation, which is lost during conversion to
kotlin.annotation.Repeatable. To support j.l.a.Repeatable in backend
properly, it's absolutely necessary to be able to load the container
annotation for any repeatable annotation class, so the original
j.l.a.Repeatable needs to be stored in the descriptor and accessible
from the backend.
Instead of mapping j.l.a.Repeatable -> k.a.Repeatable, add a frontend
service PlatformAnnotationFeaturesSupport that will determine if an
annotation is repeatable "according to the platform rules", which for
JVM means that it's annotated with j.l.a.Repeatable.
Some effects of this change include:
- Usages of j.l.a.Repeatable are no longer reported as "deprecated", the
corresponding test is deleted
- Usages of repeatable annotations declared in Java with non-SOURCE
retention with LV 1.5 and earlier will now result in a slightly
different error (REPEATED_ANNOTATION instead of
NON_SOURCE_REPEATED_ANNOTATION)
#KT-12794
Tianyu Geng