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
This reverts commit a3055edda9.
It turns out, this re-introduces an AssertionError at ClassId.<init> ("Class
name must not be root") when LazyJavaPackageScope#getContributedClassifier is
called during SAM constructor resolution below in
LazyJavaPackageScope#computeNonDeclaredFunctions, which was overlooked at the
time the commit was pushed
Use it in LazyJavaPackageFragment#scope instead of a weird lazy chained scope.
Also move lookup tracker records to it, to prevent them from being written in
each package scope individually (this was hurting performance)
Do not try to load classes (and litter in ClassDeserializer#classes cache with
unsuccessful requests) which the deserialized scope knows nothing about. This
is possible because deserialized scopes have the full list of their class names
Alexander Udalov