<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.
- Move experimental coroutines out of the main source root.
- Include experimental coroutines into the coroutines source set.
- Include release coroutines into the main source set.
Minimize AnnotationsImpl to leave it usable in simple scenarios where
there's no use-site targeted annotations, and use TargetedAnnotations in
the only place in the frontend (AnnotationResolverImpl) where use-sites
were needed.
Also, delete kdoc on Annotations.isEmpty to prevent readers from putting
too much thought into how it works. With the exception of a few places
in the frontend where use-site targeted annotations are still accessed
via the Annotations object, it's now an implementation detail and users
(such as backends, IDE) should not care about them at all, and instead
should just deal with the correct element when processing annotations
After this commit, it's overridden only in AnnotationsImpl and
CompositeAnnotations.
Note that although FilteredAnnotations did have a non-trivial
implementation, that class was only used in circumstances where
annotations with use-site targets could not be of any use, so it's safe
to return empty list there now. One could argue that the new semantics
makes more sense: filter "standard" annotations, but don't touch those
with use-site targets because they are not applied to this element
directly, thus should likely not be affected by the filtering
LazyAnnotations are only used for classes and files, and in the latter
case it will now contain file annotations as normal annotations, without
the target "file:"
Instead of returning the list of targeted annotations in
loadCallableAnnotations, add two separate methods to load annotations on
the backing field and on the delegate field of the property
This does not break or fix any behavior except the fact that
deserialization will now not try loading annotations on a property which
had no binary- or runtime-retained annotations in the sources
Dmitry Petrov