This commit also introduces separate scope processors:
processFunctionsByName and processPropertiesByName, in addition to
existing processClassifiersByName
Ad-hock call resolver starts to discover ambiguities, which leads
to some ambiguity problems in MPP tests with deep supertype hierarchy
Related to KT-29636
This commit prioritizes inner scopes above outer scopes
(before this commit, inner scopes had lowest priority).
NB: really it's not precise enough too,
because explicit importing scope should have higher priority
than inner scopes.
Also fixes problem with total Kotlin resolve test introduced
in previous commit.
Initial member scopes cover top-level, class-level, and supers
Ad-hock version of call resolve was introduced to test them
NB: after this commit, total Kotlin resolve test cannot finish
because of scope problems in type resolve transformer
Related to KT-24078
#KT-24083 Fixed
The generated code is more inline with java, and we avoid the error of
accessing package-private field outside of the package.
However, this changes semantics a bit. Now, a user should set assertion
status of inline-site's package, instead of inline function's one.
#KT-28317: Fixed
Context without expected type became redundant after synthetic
call resolving was added for inference of `if` expression type
`isStatement` flag removed, because it was effectively unused
The root problem is the fact that ConstantExpressionEvaluator returns
null for values such as infinity and NaN loaded from cls psi (see
IDEA-207252). This commit simply reverts a part of 8ab9226805 where we
started to compute default values more often than needed. In
LazyJavaClassMemberScope, we only need to check whether or not there
_is_ a default value, not compute its value.
#KT-29792 Fixed
This code can be invoked early, during body resolution and before the
fact that a property has backing field (which is only known for certain
after body resolution, because an implicit 'field' identifier may be
used). Since split annotations are cached until the end of the program,
they may end up on incorrect elements in the bytecode (or disappear
completely) as in KT-29507 or KT-28182.
Because the FIELD target has the lowest priority among implicit
annotation targets (see TARGET_PRIORITIES), it's safe to always assume
that FIELD is a valid target when splitting annotations. This only
changes the way annotations are split in case of incorrect code, as
changes in test data show.
#KT-28182 Fixed
#KT-29507 Fixed
In constructs such as 'd[i] += x', where both indexed get and indexed
set are dynamic calls, it's safe to generate augmented assignment body
directly, without temporary variables for array ('d') and index ('i').
Note that corresponding IntermediateValue's are OnceExpressionValue's,
which would throw an exception if this assumption is violated.
Mikhail Glukhikh