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
This commit reverts 59e2101a25 partially,
leaving only the implementation of KT-25972 for JVM. The reason is that
we can't fully commit to stabilizing JS (and .kotlin_metadata) binary
metadata formats so much as to postpone any changes done to it for a
whole release year time. It's likely that we will need to update JS
metadata format incompatibly pretty soon, and with the scheme where we
can read the "current + 1" version, it'd require advancing the metadata
version by 2, which would break the nice property that the metadata
version (since Kotlin 1.4) is equal to the version of the compiler that
produced it.
See KT-25972
This reverts commit ba111d58ae.
The reverted commit only makes sense after a bootstrap step after
advancing the metadata version, which has not yet happened in master,
but did happen in 1.3-M2, where this commit was supposed to end up
Natalia Selezneva