All bytecode text tests are run with stdlib in the classpath and only
for JVM backend, therefore directives WITH_RUNTIME, TARGET_BACKEND,
IGNORE_BACKEND are not needed
Test data of crossinline_1_2.txt has changed because now we do not
automatically enable 1.2 (with _all_ of its features) when we're
executing a common coroutines test with old coroutines; and so the
NewCapturedReceiverFieldNamingConvention language feature (which is
introduced in 1.3) is now enabled in this test
Use `// !LANGUAGE: -ReleaseCoroutines` instead in tests which require
old (1.2) coroutines, and nothing in tests which require new coroutines
because master is already 1.3. Also remove superfluous API_VERSION and
other directives which have no effect anymore. Do not include runtime
automatically with `WITH_COROUTINES`/`COMMON_COROUTINES_TEST` in box
tests; require `WITH_RUNTIME` for that (majority of tests already had it
anyway), but remove it from bytecode text tests where runtime is always
added automatically. Fix the coroutine package selection code in
KotlinTestUtils and update the bunch files correspondingly.
Disable tests in `box/coroutines/noStdLib` on JVM: despite the name,
these tests were launched with stdlib because of the code in
CodegenTestCase, and they do not work without it because at least
CoroutineUtil.kt requires stdlib to compile correctly
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
It helps to generate properly the annotations for delegates
Also note in test, that annotations in Base class have really weird
text of arguments and also don't have names
Instead of trying to access a missing field `Foo.foo`, call the
synthetic accessor `Foo.access$getFoo$cp` which, as per previous commit,
no longer contains the lateinit assertion
#KT-21862 Fixed
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
This fixes the most common (and rather annoying) bug in augmented
assignment desugaring with collection element receiver.
Fix is somewhat hackish: introduce an intrinsic for MutableMap.set,
thus bypassing discrepancies in 'get' and 'set' call generation.
Fixing it properly requires design decisions for corner cases where
ad hoc augmented assignment desugaring with collection element receiver
"accidentally" works, producing identical objects and vararg arrays for
arguments of 'get' and 'set'.
Input and output types are crucial for type variable fixation order and
analysis of postponed arguments (callable references, lambdas).
Specifically, if there is non-fixed type variable inside input types of
a callable reference, then we'll postpone resolution for such callable
reference.
Initial example with the expected type `KMutableProperty1<*, F>` caused
problems because input types were computed incorrectly (while there
aren't input types here)
#KT-25431 Fixed
It's needed to estimate the count of steps for type approximation algorithm.
After the estimated count of steps, we consider such type recursive and this
algorithm returns some default value
#KT-28598 Fixed
KtLightNullabilityAnnotation is specifically designed for old light classes
and includes a bunch of hacks that are applicable for them
So, we have to introduce own hack into it
(see org.jetbrains.kotlin.asJava.classes.KtUltraLightParameter#getTypeForNullability)
that is a bit of hard to support when extending hierarchy
Alexander Udalov