Most of these tests used this directive as a way to opt in to a new
language feature, and most of those features are already stable for a
long time, so no opt-in is needed. Some other tests used the directive
to opt out from a language feature, replace those by the `LANGUAGE`
directive. One test used the directive to test behavior that actually
depended on the API version; use `API_VERSION` directive there instead.
See `ExpressionCodegen.genEqualsForExpressionsPreferIeee754Arithmetic`:
the behavior here actually depends on the API version, not any language
feature
Previously, for a property named `x` in the companion object of a class
named `Foo`, we generated:
- `Foo.access$getX$cp`, consisting of `GETFIELD Foo.x` and lateinit
assertion
- `Foo.Companion.getX`, consisting of `INVOKEVIRTUAL Foo.access$getX$cp`
Now, we generate:
- `Foo.access$getX$cp`, consisting of `GETFIELD Foo.x`
- `Foo.Companion.getX`, consisting of `INVOKEVIRTUAL Foo.access$getX$cp`
and lateinit assertion
The reason is that this way we can avoid generating another accessor and
reuse `Foo.access$getX$cp` in case `isInitialized` is called on a
lateinit property from companion.
For private properties, getX is not generated, but instead the assertion
is generated on each access to the field (which can be improved, see
KT-28331). The same happens for access to non-private properties from
inside the same context where they're declared.
#KT-21862 In Progress
Sometimes, state-machine, generated in inline functions with
crossinline parameter, is transformed, since all usages should be
renamed.
However, this is wrong: in this case, we will have state-machine
inside state-machine.
This fix addresses the issue.
#KT-25893 Fixed
* The members of Result are isSuccess, isFailure, exceptionOrNull, getOrNull
* The rest of API is implemented via inline-only extensions
* There are two internal functions to hide detailed mechanics of an internal
Result.Failure class: createFailure and throwOnFailure
* Result.toString is explicit: either Success(v) or Failure(x)
See KT-26538
<IMPL_SUFFIX> for method is a method signature hash,
if method value parameter types contain inline class types,
otherwise 'impl'.
Constructor methods are named as 'constructor-<IMPL_SUFFIX>'.
Synthesized 'box' and 'unbox' methods are named as
'<METHOD_NAME>-<IMPL_SUFFIX>'.
Erased implementations of overriding and non-overriding methods
are named as '<METHOD_NAME>-<IMPL_SUFFIX>'.
Fully specialized implementation of 'equals' will have a special suffix.
We might want to add 'init' blocks later, so now, for the sake of
binary compatibility with 1.3-RC binaries, we have to generate these
'constructor' calls.
Note that in some tests inline class boxing is no longer redundant,
because resulting value is passed to 'constructor' as an argument.
Avoid name clashes in cases such as
inline class Login(val login: String)
inline class Password(val password: String)
fun validate(login: Login) { ... }
fun validate(password: Password) { ... }
Fix for test data (inlineFunctionInsideInlineClassesBox.kt) is needed
to avoid check about "no inline functions".
This check has two steps: first, names of inline functions from
the metadata are loaded, then these names are checked that they are
presented for physical methods in the classfile.
Because now there are no physical methods in the classfile, we can't pass
the second check, therefore this fix is needed.
#KT-24872 Fixed
The changes are necessary because of release coroutines support:
- Get rid of suspendCoroutineOrReturn calls. It's anyway irrelevant
to what is being tested here
- In varValueConflictsWithTable.kt, variables slots have been shifted
because the variable for continuation's exception was removed
- In varValueConflictsWithTableSameSort.kt, a variable has been introduced
to preserve the same slot numbers for old variables.
Otherwise, they become shifted and to the second slot,
and there are a lot of irrelevant "ALOAD 2" instructions
This change is another example of why bytecode text tests are evil
