Note that now DeserializedClassDescriptor.getSealedSubclasses works a lot
faster than before, for all newly compiled sealed classes except empty ones. It
may be optimized further if we look at the metadata version of the file the
class was loaded from, however it's not easy currently because
DeserializedClassDescriptor is declared in common (non-JVM) code and has no
direct access to the binary version information.
This will also allow to add a reflection API to get subclasses of a sealed
class
#KT-12795 Fixed
'SuspendFunction$n' class descriptors are created on demand by KotlinBuiltIns (and cached).
On serialization, types constructed with 'SuspendFunction$n' are written as 'Function$n' with extra flag (SUSPEND_TYPE).
On deserialization, corresponding 'SuspendFunction$n' classes are used.
This is a way for future compilers to cause previous compilers to report
diagnostics on usages of some declarations. Diagnostic can have a message
(and/or error code), level (error, warning, or completely hide the declaration
from the resolution), and Kotlin version, since which the diagnostic should no
longer be reported
Similarly to pre-release classes, load metadata for the class anyway and allow
the resolution to select it as the result and prohibit its usage in the end
with the special diagnostic reported in MissingDependencyClassChecker
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
When "-language-version 1.0" is specified in command line arguments, the
compiler should not be able to see the declarations of type aliases in
libraries, because that corresponds to the behavior of the compiler of version
1.0. Note that type aliases are _completely invisible_ in this mode (i.e.
"unresolved reference" is reported) because they must not interfere with the
classifier resolution
Do not split descriptors into declared/non-declared groups
It should not be important as order of non-declared members' appearance
does not affect stub building, deserialization and other order-sensitive
stuff
Do not use memoized function if member with given name is not contained in the scope
There are a lot of queries with names of non-existent functions, that
leads to many effectively redundant Map nodes in MemoizedFunction and also cause
additional computation that is worth to compute at once
Also drop unused 'location' parameter
Currently it's only used for local type aliases, while code in
'deserializeTypeAlias' works properly only for nested or top-level type
aliases.
Also it seems that serialization of types based on local type aliases
doesn't work now anyway (see KT-13692)
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
Since public type aliases will supposedly be more common than internal ones, it
makes sense to save on writing flags for the former rather than the latter
Alexander Udalov