This keeps behaviour consistent in rare cases when JavaClass can be found but not resolved
As of now this can happen in IDE if we take PsiClass from index but file structure is wrong so we can't resolve the class
Add test which documents this case
Get rid of Kind in JavaPackageFragmentDescriptor and create subclass which exposes additional function
Add method in JavaClassDescriptor to get correponding package fragment
Remove JavaDescriptorResolver from context
Remove LazyJavaClassResolverWithCache
This actually can affect behaviour because JavaResolverCache has slightly different logic (uses CLASS key in BindingContext as opposed to FQNAME_TO_CLASS_DESCRIPTOR)
This reverts commit 1d21ebf882.
Conflicts:
compiler/testData/builtin-classes.txt
core/descriptors/src/org/jetbrains/jet/renderer/DescriptorRendererImpl.java
Reverting a part of this (related to the field 'prettyFunctionTypes') because
will need to add a test that deserialized built-ins (obtained by
KotlinBuiltIns.getInstance()) are consistent with lazy resolved built-ins. This
test would break because while DescriptorRenderer renders pretty function types
it compares descriptors to the ones from KotlinBuiltIns, but in case of lazy
resolve descriptors created for built-ins would be different from
KotlinBuiltIns, so renderer wouldn't correctly render a function type
This is needed because until we have modules and dependencies implemented in
our IDEA plugin, the whole project always is analyzed to highlight any file in
the project. This resulted in weird errors in different modules in Kotlin
project because two declarations were found for each built-in class: the one in
kotlin-runtime.jar and the one (totally unrelated) in the 'builtins' module
Don't store binary data in the repository anymore. From now on any test on the
compiler requires that 'ant dist' was executed at least once since the last
update of the built-ins
Unit.VALUE is annotated right now (with "suppress"), so deserialization was
throwing an exception from AnnotationDeserializer.UNSUPPORTED. Return empty
collections of annotations instead; here we use the fact that it's the only
annotation in built-ins and its presence is useless to the type checker
BuiltInsSerializer now serializes built-ins found in two source roots:
core/builtins/native and core/builtins/src
Add return types to some declarations in core/builtins/src, because now that
BuiltInsSerializer processes them, it launches lazy resolution which can't
always deduce the return type
'builtins' will be used for platform-independent core built-in definitions,
'runtime.jvm' for things that should be present at runtime in order for Kotlin
code to execute correctly on JVM
ProgressionUtil goes to 'builtins' right now because progression iterators
depend on it, but should be rewritten to Kotlin later
Svetlana Isakova