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
Add PropertyDescriptor.backingField/delegateField to store annotations
on the field directly in an otherwise almost empty descriptor instance,
instead of storing them with use-sites in the corresponding property
descriptor. Instead of AnnotationWithTarget, create AnnotationDescriptor
instances in AnnotationSplitter. Change DescriptorRenderer to render
annotations on "related" declarations when needed, with the explicit
use-site target if applicable.
Most changes in diagnostic test data are related to the fact that
annotations which are known to have an incompatible use-site to the
declaration they're applied at (such as `@param:`-annotation on a
function), are now not loaded at all. It's fine because the code is
erroneous, so it doesn't really matter how do we load annotations with
invalid targets (some of this logic is also changed freely in subsequent
commits). Some changes are also explained by the fact that for example
an annotation on the property which is only applicable to FIELD is now
rendered with an explicit use-site target `@field:`, regardless of
whether it did have that use-site target syntactically or not.
Basically, after this change there's no point in calling
Annotations.getUseSiteTargetedAnnotations/getAllAnnotations anymore
because it's easier and more intuitive to just use Annotations of the
corresponding descriptor -- the backing / delegate field (introduced in
this commit) or the extension receiver / setter parameter (related
behavior was fixed in previous commits). Usages of
use-site-target-related methods will be refactored out in subsequent
commits
For example, previously on an (incorrect) code like
@setparam:Ann
val x = 42
We added Ann to x's annotations. Not doing this seems more correct and
simplifies implementation a bit.
Test data is NOT changed in this commit because effective changes
somewhat depend on the changes in the subsequent commits. Affected tests
are at compiler/testData/diagnostics/tests/annotations/withUseSiteTarget
Make it possible to specify annotations of the setter parameter when
constructing the default setter via DescriptorFactory; pass the split
annotations in DescriptorResolver.resolvePropertySetterDescriptor
#KT-25500 Fixed
Note that this change brings an incompatibility: `Array<Foo>::class`
will be seen as `Foo::class` by the old deserializer. We consider this
OK because the compiler never had any logic that relied on reading class
literal arguments correctly (otherwise it wouldn't have worked because
it could only see `Array<*>::class` before this commit), and the support
of annotations on types in JVM reflection is only available in the
upcoming 1.3 release (KT-16795)
#KT-22069 Fixed
This commit effectively reverts
d386712903.
The reason is that when using a release language version, you can only
"see" the subset of a pre-release library which consists of released and
supported features, so reporting an error is not helpful there. Also, it
presents a problem currently when using kotlinc 1.3 (which is
pre-release) with language version 1.2 (stable) against the bundled
stdlib of version 1.3 (pre-release)
#KT-21267 Declined
This change would also make NotNull annotations to be generated on
non-primitive annotation methods, but we skip this deliberately because
annotation methods never return null on JVM anyway
#KT-25287 Fixed
This will make it possible to avoid raw types when inheriting from both
FunctionBase and Function<R>. This change adds a generic type parameter
to FunctionBase and Lambda which is not source-breaking under our policy
because both FunctionBase and Lambda are internal classes (located in
package kotlin.jvm.internal)
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
JVM versions are increased in order to differentiate pre-1.3-M2 .class
files where signatures mentioning inline classes were not mangled. Other
versions are increased in case something similar will need to be
detected
This commit reverts f6571effcc and
reimplements the desired logic in another way.
In particular, we'd like these two conditions to hold:
1) only the release compiler with stable language settings (meaning,
language version is a released version of Kotlin and no experimental
features are enabled) should report errors when _reading_ pre-release
binaries.
2) the compiler should _write_ pre-release binaries only if language
settings are not stable, independent of whether the compiler itself
is release or not.
From these conditions it follows that we must use different logic to
determine how to behave when reading/writing pre-release binaries.
Namely, reading (in CompilerDeserializationConfiguration) now checks if
both the compiler is release and the language settings are stable, and
writing (in LanguageVersionSettings.isPreRelease) checks only that the
language settings are stable
This commit effectively reverts
d386712903.
The reason is that when using a release language version, you can only
"see" the subset of a pre-release library which consists of released and
supported features, so reporting an error is not helpful there. Also, it
presents a problem currently when using kotlinc 1.3 (which is
pre-release) with language version 1.2 (stable) against the bundled
stdlib of version 1.3 (pre-release)
#KT-21267 Declined
Already existing tests testRequireKotlinInNestedClassesAgainst14{,Js}
now check that there's no error when loading a module/class with
metadata version 1.4.0
#KT-25972 Fixed
Otherwise this code behaves incorrectly on getter-only properties: it
returns a meaningless field signature whereas the property has no field.
It's hard to come up with an example of when this could matter in
compiler code, but it's very noticeable in kotlinx-metadata-jvm
#KT-26188 Fixed
This should have no effect on the correct code currently because all
properties have at least a getter, but may help in debugging problems
with serialized metadata for properties
Metadata for declarations in multi-file classes is always written to the
corresponding parts, but fields for public const vals are generated into
the facade class.
Before this change, we ran generateBackingField only to generate the
const val field in the facade (because isBackingFieldOwner is true only
for the facade). Besides generating the actual field,
generateBackingField also stores the mapping to the FIELD_FOR_PROPERTY
slice, which is used later in the serializer to serialize the correct
JVM signature of the field to the metadata. However, the mapping was
stored to the incorrect binding map! Namely, the map from the same
ClassBuilder that is used to generate the class, and that is the facade
class builder. But the metadata needs to be generated to the part class,
not the facade.
Surprisingly, there is a test at
reflection/multifileClasses/javaFieldForVarAndConstVal.kt that checks
that kotlin-reflect is able to load the field signature of a const val
in a multi-file class, which is the main use case of this information,
and it passed before this change. The reason the test passed is that
KPropertyImpl.javaField uses JvmProtoBufUtil.getJvmFieldSignature which
mistakenly treats the absence of the field signature in the proto as the
hint that it may be computed naively (just the property's name + naively
mapped type), whereas in fact the field signature was missing
completely. (The fact that absence of a message may mean two things is
certainly a shortcoming of the metadata format and should be revisited
in the future.) This never led to any problem in the real world because
it's easy to prove that the field signature of a const val can always be
computed naively.
After this change, we now run generateBackingField twice: for the
facade's class builder, and for the part's class builder. The actual
field is only generated in the former case. But the mapping computed in
the latter case is used correctly in JvmSerializerExtension to store the
field signature to metadata. Also refactor
generateSyntheticMethodIfNeeded in the similar way, to reduce the number
of `if`s.
This has no effect on the correct code currently, but will help in
debugging when changing the serialized metadata for properties.
For example, if after some change an empty propertySignature extension
is written for Property (it's possible for PropertyDescriptor without
getter or setter and without backing field), we now won't try to read a
missing getter message when loading annotations on property getter. In
protobuf, reading a missing message will result not in an exception, but
in a "default" message being returned, which makes no sense in our case
because it would simply be read as a getter signature with both "name"
and "desc" equal to 0 (i.e. the first entry in the string table)
This is still not 100% foolproof because one may place such a
requirement manually on a suspend function (with `@RequireKotlin`, for
example), which will trick the compiler into thinking that this is a new
suspend function, even if it was compiled with old coroutines. But it's
still better than only checking the version number
Comparing files by paths is too error-prone and it created a problem
here, where paths of File instances on Windows use "\" as a separator,
whereas VirtualFile paths always use "/", resulting in empty source
lists being compiled. This issue was introduced in 1582354077. Instead,
get the instance of the VirtualFile by path, and use its identity for
comparison
Do not call this method the second time in KotlinToJVMBytecodeCompiler
where all KtFile instances are already created; just get only those
files that are in the needed module, which can be determined solely by
the file path.
Also "kotlinize" getKtFiles and rename to createKtFiles
Otherwise the "outputDir" in these tests was treated as relative to the
project root, and starting from 63b4302cea, running these tests resulted
in the "whatever" directory being created in the project root
To be able to use it correctly inside an xml build file where, if the
path is not absolute, it's treated as relative to the build file path
(which is TMP_DIR in several tests of the subsequent commit)
In case of a bridge for a vararg invoke with big arity, the bridge only
has one parameter (array of parameters), and the delegate method has at
least 23 parameters. This assert was added in 77959247d2 and it didn't
cause any tests in master to fail because tests on functions with big
arity are disabled there
Alexander Udalov