Also add a findInnerClass method that can find an inner class
by its name
This change helps to avoid loading all the inner class files
eagerly (that may be rather slow), while all the names are available
in InnerClass attribute
The reason is that canonicalText requires some additional
computations to be done when reading class files, while
in fact we only need a class name of the type
Previously ReflectionTypes.find returned an error class in case a class
is not found in the module dependencies. The problem with this approach
is that each call site should call ErrorUtils.isError on the result and
report an error if needed, in order to stop this type from reaching the
codegen, which can't handle error types.
Now we create a MockClassDescriptor instance instead. It's not an error
class, so it'll be handled correctly in the codegen. Also its scope is
empty and errors are reported on any non-trivial usage (see
MissingDependencyClassChecker), so this approach is not worse than error
classes
#KT-16484 Fixed
Before creating a MetadataPackageFragment, check that the corresponding
directory (across the classpath) contains at least one .kotlin_metadata file.
Otherwise we're creating packages for every simple name queried during the
resolution and sometimes prefer a (empty) package to the existing class, for
example when the latter class is star-imported
Extract AbstractDeserializedPackageFragmentProvider out of
JvmBuiltInsPackageFragmentProvider and implement it a little bit differently in
MetadataPackageFragmentProvider. The main difference is in how the package
fragment scope is constructed: for built-ins, it's just a single scope that
loads everything from one protobuf message. For metadata, package scope can
consist of many files, some of which store information about classes and others
are similar to package parts on JVM, so a ChainedMemberScope instance is
created.
Introduce a bunch of interfaces/methods to deliver the needed behavior to the
'deserialization' module which is not JVM-specific and does not depend on the
compiler code: MetadataFinderFactory,
PackagePartProvider#findMetadataPackageParts, KotlinMetadataFinder#findMetadata.
Note that these declarations are currently only implemented in the compiler; no
metadata package parts/fragments will be found in IDE or reflection
Introduce a new method KotlinClassFinder#findBuiltInsData, which is only
implemented correctly in the JvmCliVirtualFileFinder because it's only used in
the compiler code at the moment.
Introduce JvmBuiltInsPackageFragmentProvider, the purpose of which is to look
for .kotlin_builtins files in the classpath and provide definitions of
built-ins from those files.
Also exclude script.runtime from compilation because, as other excluded
modules, it has no dependency on the stdlib and is no longer compilable from
the IDE now, because it cannot resolve built-ins from anywhere
Just reporting error by call checker may be too restrictive
in case there are some extensions that can be used successfully
Solution is to annotate additional members with
@Deprecated(level=Error) + @kotlin.internal.LowPriorityInOverloadResolution
If deserializing a type with arguments based on a local class for
decompiler, then just return Any type (without arguments).
Previously Any constructor was used with serialized arguments, that lead
to exception
Note that in case of deserialization for compiler nothing changes about
local-classes-based types (LocalClassifierResolverImpl is just inlined)
#KT-13408 Fixed
As in KClassifier.createType and everywhere in the compiler, specify arguments
for the innermost type first. This is more convenient to use because generally
the construction/introspection of such type starts from the innermost class
anyway (i.e. something like generateSequence can be used, without the need to
call .reverse() in the end)
- Move components from LazyJavaResolverContext to JavaResolverComponents
- Drop LazyJavaClassResolver replacing it's usages with module resolver
(now enum entries from another module as annotation arguments are being resolved, see test)
The main change is in AbstractBinaryClassAnnotationAndConstantLoader, where we
no longer perform unnecessary IO operations for classes which are already
loaded to memory
Use the same component (NotFoundClasses) as in loading of compiled Kotlin
symbols.
Some tests were changed to avoid a diagnostic that is now reported when a
non-found class is encountered in a signature (e.g. staticMethod.1.java where
JDK seems to be not configured)
#KT-10493 Fixed
#KT-10820 Fixed
#KT-11368 Fixed
Denis Zharkov