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
Ilya Gorbunov