`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
Before 1.6 we wrote suspend functional types with last parameter of
kotlin.coroutines.experimental.Continuation type to .kotlin_metadata
files. For example, kotlin-stdlib-common. Thus, we need to read
them, since coroutines have been released in 1.3 and we need to be able
to read stable binaries.
Anonymous objects in the scope of an inline functions are copied to
all call-sites. This makes them part of the public ABI of a Kotlin
library.
We introduce a flag to mark all classes in the scope of an inline
function. When compiling with assertions enabled, we check that
this flag is set whenever we inline an anonymous object from another
module.
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)
pyos