When a property backed by a final field is the delegate for interface
implementation by delegation, the backend should reuse the backing
field rather than introduce a new, extraneous `$$delegate_n` field.
Unknown lambda parameter should not change resolve.
So the new diagnostic should not have error status; othrewise candidates with lower priority but more specific expected type may be chosen.
KT-34335 Fixed
See also KT-36264
Set first supported version to 1.3
Add property for oldest depecated language version in order to control unsupported ones
Report error on attempts to manually disable language feature from unsupported versions
Update test data, drop compatibility tests for features from unsupported versions
KT-36146 In progress
* remove test roots in modules which have no tests
* 1.8 is already the default JVM target in the project
* replace compilation dependency on kotlin-reflect with runtime
This change adds D8 in addition to Dx which is being deprecated.
At some point after the official Dx deprecation, we should remove
the Dx checker.
Moving to D8 has the additional benefit that D8 can dex code
using java 8 features without using a separate desugaring tool.
From now on, the old JVM backend will report an error by default when
compiling against class files produced by the JVM IR backend. This is
needed because we're not yet sure that the ABI generated by JVM IR is
fully correct and do not want to land in a 2-dimensional compatibility
situation where we'll need to consider twice more scenarios when
introducing any breaking change in the language. This is generally OK
since the JVM IR backend is still going to be experimental in 1.4.
However, for purposes of users which _do_ need to compile something with
the old backend against JVM IR, we provide two new compiler flags:
* -Xallow-jvm-ir-dependencies -- allows to suppress the error when
compiling with the old backend against JVM IR.
* -Xir-binary-with-stable-api -- allows to mark the generated binaries
as stable, when compiling anything with JVM IR, so that dependent
modules will compile even with the old backend automatically. In this
case, the author usually does not care for the generated ABI, or s/he
ensures that it's consistent with the one expected by the old compiler
with some external tools.
Internally, this is implemented by storing two new flags in
kotlin.Metadata: one tells if the class file was compiled with the JVM
IR, and another tells if the class file is stable (in case it's compiled
with JVM IR). Implementation is similar to the diagnostic reported by
the pre-release dependency checker.
This fixes an issue with lateinit properties where the metadata from
the original field was not copied to the nullable field in
LateinitLowering. Also consolidated related tests.
Mikhail Glukhikh