'hasDefaultValue' needs to be adapted to support locating default values
in 'expect' functions, and this is not possible in module 'descriptors',
where it was originally declared. Therefore, move it to module
'resolution' and copy its current logic to a separate function
'declaresOrInheritsDefaultValue' which is used in 5 places.
'hasDefaultValue' itself is updated in subsequent commits.
Besides changing imports, also use a simpler declaresDefaultValue in
some places, which does not include default values inherited from
supertypes: this is OK for constructors, and in LazyJavaClassMemberScope
for functions from built-ins which do not have default argument values
at all
Object model for deserialized protobuf isn't very cheap, so
loading just our stdlib's packages several times (as we do in the IDE)
might lead to ~ 96 MB of retained memory just by these objects.
While in fact many of them remain unused
#KT-21517 Fixed
Only store the ClassId of the enum class and the Name of the entry, and
resolve the needed descriptor in getType() instead, which now takes the
module instance where that descriptor should be resolved
Using the argument value, which is of type "Any?", is more implicit and
thus difficult to read than using the ConstantValue instance and casting
it to the needed constant value implementation before taking the value
Only require implementations to be able to compute the enum class name
and the corresponding entry name. Only this should be necessary to
correctly resolve the argument; the resolvers will find the
corresponding class descriptor if necessary
Remove KotlinBuiltIns and take a ModuleDescriptor instance in getType
instead. This will allow to create constant values in contexts where
there's no module or built-ins accessible (such as, deserialization of
module annotations during indexing of .kotlin_module files in IDE).
Note that some values (KClassValue, EnumValue, AnnotationValue) still
take module-dependent objects (KotlinType, ClassDescriptor and
AnnotationDescriptor respectively). This is to be refactored later
It's implemented through Jsr305State while it's not related
to jsr-305 becasue currently it's the most convenient way
to introduce the flag.
Probably, it's worth renaming Jsr305State to something more abstract
like NullabilityAnnotationsConfiguration
#KT-21982 Fixed
We are migrating Guava to use these annotations rather than jsr305's
@Nullable. We can't use the Checker Framework's _@Nullable_ yet because
we promise compatibility with Java 7, which doesn't support type
annotations. This is related to but distinct from
https://youtrack.jetbrains.com/issue/KT-21408, which is about a
different jsr305 annotation we use, @ParametersAreNonnullByDefault.
I've also updated some docs to mention Kotlin's existing support for the
Checker Framework _@NonNull_.
Consider all callable descriptor in JavaClassDescriptor to be from Java.
This is used to check if smart step into should be intercepted by Kotlin
handler or delegated to Java.
#KT-21538 Fixed
It's purpose is passing java classes being used during analysis
to incremental compilation to let it track diffs
Potentially it might be done the other way:
incremental compilation could build a separate container to analyze
necessary classes, but it's rather hard to implement now
#KT-17621 In Progress
The new name is more convenient and precise because this module is no
longer only about loading declarations from Java, it also contains
implementation of loading Kotlin declarations from .class files, as well
as type mapping abstractions, JVM ABI specifications, etc.
Denis Zharkov