The design is to use `suspend fun` instead of coercion, just as suspend
lambdas.
However, this syntax is not supported in the parser. But this is not a
problem, since the coercion lead to internal compiler error.
As a workaround everybody uses suspend lambdas.
#KT-24860: Fixed
Pre-release compiler should be able to read pre-release binaries in tests
even if a stable language version is used, otherwise no stdlib API can be read.
Set LATEST_STABLE language version and current version of stdlib to 1.3, set IS_PRE_RELEASE
Remove "EXPERIMENTAL" from 1.3 version description in tests and gradle options
In 4f3f4dd, launch(EDT(project)) was replaced with TransactionGuard.submitTransaction to fix write in write-unsafe context.
Unfortunately submitTransaction will call action immediately if we are already on EDT. This causes IDE freeze.
By replacing submitTransaction with submitTransactionLater we are postponing work to the end of events queue (as it was before 4f3f4dd).
Also in isUnitTestMode we need to call action immediately as it was before 4f3f4dd.
#KT-25958 Fixed
Android Studio has at least two kinds of importers: a generic one (that is run when the "Refresh Gradle model" tool button is pressed) and a fast one (is run on the build variant switch). Fast importer doesn't invoke our import handlers (AndroidExtensionsGradleImportHandler) that modify the compiler options stored in Kotlin facet in some way.
Until the recent MPP importer refactoring both old and new options were saved in the Kotlin facet; now only the new options persist. This is certainly better, though it breaks the existing behavior (as the options added by import handlers become lost).
The alternative approach is to re-design import handlers in a way they won't require the whole module/source set node (so we can invoke them every time), though it requires a way more changes.
This PR enables LineNumberTestGenerated test on IR backend. The testing of
hardcoded sequence of line numbers is replaced with mere checks for set-like
checks for expected line numbers.
In some tests with txt (probably all except loadJava), property
accessors are not rendered at all, so a third option value (NONE) will
be useful to determine whether we need to render annotations on property
accessors as get/set/sparam-targeted annotations on the property
Only use the other setType that takes an instance of
ReceiverParameterDescriptor. This will make sure that call sites can
use correct receiver annotations
Otherwise (after subsequent commits) we may end up calling
BindingContext.HAS_BACKING_FIELD too early and getting incorrect value,
which will influence which annotations the property and the field will
have, and since they're cached as soon as they're computed, they will
remain incorrect until the end of the program. Now we're calling force
resolve after bodies of property accessors are resolved, which is the
point where the backing field presence has been already determined for
certain.
This all still looks very fragile because we might try to get property's
annotations anywhere else before the accessors' bodies are analyzed, but
I have no idea at the moment how to improve this without refactoring the
whole subsystem
Ilya Gorbunov