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.
NB1 Not every dynamic unary or binary expression is translated to
dynamic operator expressions literally. For example, assignments and
increments can have safe calls in LHS, which require some extra logic.
NB2 There are some open design questions left regarding how dynamic
expressions should actually be translated.
Split the ConstAndJvmFieldPropertiesLowering into two: ConstLowering
which replaces const vals with their values, and
PropertiesToFieldsLowering which removes unnecessary property accessors
(such as for JvmField or private properties with default accessors) and
replaces calls to those accessors with field access
The boundWithSerializableReceiver.kt test is muted since property
references are not yet supported in the JVM IR backend. Previously it
passed by accident
In InnerClassesLowering, the type of the "outer$0" expression should be
the outer class, not the inner class. In EnumClassLowering, the type of
the enum entry is the type of its class or the type of the enum class,
but not the type of initialierExpression which is always Unit
IrDeclarationOrigin.FILE_CLASS is used in CallableReferenceLowering to
generate correct declaration owner.
Many reflection tests start to fail with this commit because they are
now treating callable references to top level declarations as Kotlin
symbols and fail because there's no JVM signature for them; this is
fixed in subsequent commits (previously, they worked because without
Kotlin metadata, these files were treated as Java classes)
After one of previous commits (my or Mikhail Zarechenskiy) that test
was broken and it's behaviour was not fixed. That test's behaviour
is strange (why at one case we have `UNREACHABLE_CODE` and haven't
at other) and needs further investigation
Code such as
```
val b = getBoolean()
if (b) 4
else if (b) 5
```
didn't generate a value on the stack always and therefore would
have control-flow paths leading to a pop instruction with nothing
on the stack.
Change-Id: I09d059f361e56a41880006e3f4e51e9acdbd167d
Initializers are "set field" expressions and are considered redundant
when they are:
1. In the primary constructor; and
2. Set the field to `0`, `false`, or `null`; and
3. Have a `null` origin. I.e., not in an initializer block or
constructor body, and therefore the field could not have been set by a
prior expression.
Add some classes to hierarchy of `ESValue`:
- `ESReceiver` -- representation of receiver
of lambda function
- `ESDataFlow` and `ESDataFlowReceiver` -- little refactoring of entities
that holds information for DFA (description in comments in code).
Also add kdoc to classes of `ESValue` hierarchy
Dmitry Petrov