"Empty" is slightly confusing because although the scope has no declared
symbols, it is not empty: it has a parent scope which can contain
symbols and can have parents as well
ScopeTowerProcessors.kt contains a few code snippets
that look like `collectCandidates(...).filter { ... }.map { ... }`.
Filter argument is always side-effect free, so it is safe
to merge `filter` and `map` calls into one for-loop.
The change also makes sense, because modified functions are quite hot.
For example `NoExplicitReceiverScopeTowerProcessor.simpleProcess`
produces 11,392,768 ArrayList instances (~1.08% of all objects)
when compiling the compiler according to aprof at the moment of writing.
On my machine the change improves compilation speed of the compiler up to 5%.
Some IDE features relates onto that same descriptors will remain same
between resolve calls
Fix it to be true for TypeAliasConstructorDescriptor's
#KT-16265 fixed
The problem was that when resolving super-calls we used known substitutor
when creating a type alias constructor, thus its original return itself,
while it's expected that it should return the descriptor before substitution
The main idea of the fix that `createIfAvailable` should always return
unsubstituted constructor.
Note that known substitutor for type alias constructor should be based
on abbreviation.
The test change seems to be correct as PROJECTION_IN_IMMEDIATE_ARGUMENT_TO_SUPERTYPE
is already reported.
Beside this, resolution behavior isn't expected to be changed dramatically
Instead of verifying that the container of an 'invoke' is a
FunctionClassDescriptor instance, make sure that it's a function class
checking its FQ name instead (classId + isBuiltinFunctionClass calls).
This makes sure that we will create synthesized invokes in a setting
where function classes are not FunctionClassDescriptor instances
synthesized by the compiler, but ordinary classes from sources or
binaries as well, as is going to be the case in kotlin-native
Actually it should not be very important, but for sake of consistency
we should use null receiver even if we have one in an outer scope
This is a post-review fix
We made it because of non-stable name resolution when project is multi platform. For such projects in platform module we have two classifiers with the same name, but impl class or type alias should win!
After this change SAM adapters are being resolved in the same group
as members, thus their overload resolution happens simultaneously.
But in the case of overload resolution ambiguity try to filter out all
synthetic members and run the process again.
See the issue and new test for clarification
#KT-11128 In Progress
Otherwise calls to functions which are declared twice (platform and impl) would
result in an error "conflicting overloads" in platform-specific modules
If a module is configured in such a way that the same function appears multiple
times via different dependencies, it's not helpful to report "none of the
following functions can be called", listing the same function multiple times
Alexander Udalov