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
CLITool.exec is used in konanc to perform compilation of native project.
Due to some internal limitation, this function runs in separate process.
After this change, there will be a possibility to choose MessageRenderer
used in CLITool.exec via system property
org.jetbrains.kotlin.cliMessageRenderer.
Reviewed at KOTLIN-CR-2698.
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.
Ilya Chernikov