There is a `gradle-api-impldep.jar` created by Gradle which contains
our nullability annotations, but relocated in the
`org.gradle.internal.impldep` package
In the deserialization process we use a `HAS_ANNOTATIONS` flag, and
if it is present on the declaration, we do not try to build annotations
for it, even when they are actually present and even when they are
relocated
(see usages of Flags.HAS_ANNOTATIONS in org.jetbrains.kotlin.serialization.deserialization.MemberDeserializer)
In the stubs builder we also use this HAS_ANNOTATIONS flag, but we did
not use it for the value parameters. This commit fixes that - now, if
the `org.jetbrains.annotations` packages are relocated, it should not
cause `Stub Mismatch Error` for the value parameters
Lets consider two possible cases:
1. If the value parameter has a user-defined annotation,
it will be marked as having annotations (HAS_ANNOTATIONS == true), and
both stubs and deserialized descriptors will have to
use all available annotations (even a relocated ones)
2. If, for example, the value parameter is of non-nullable type, it will
have a `@NotNull` annotation on it, but will be marked as having
no annotations at all (HAS_ANNOTATIONS == false), since `NotNull` is
considered as auxiliary by the compiler. Because of the flag, both stubs
and descriptors will ignore all present annotations (even if they were
relocated)
In the both cases, the stubs and the descriptors will completely match
^KT-44756 Fixed
See IDEA-262971 about fixing the Gradle jar and the details
N.B. This does not fixes the cases when `kotlin.Metadata` and similar
annotations are relocated (e.g. KT-25709)
Introduce Duration companion functions to convert numbers to Duration.
Deprecate number extension properties and propose to use these
new functions instead.
So that the lambda can contain non-local control flow, such as suspend
calls. Inline-only helps preserving line numbers in the failed assertion
stack traces.
KT-44717
We need to invoke `llvm-profdata` tool from
the same toolchain as Clang (on macOS we use the one from Xcode).
(cherry picked from commit 91665b36af68b7fb3a56c0e7ed7ebb7d819adfb2)
Allow toolchain builder to add a suffix to toolchain name.
It is useful for rebuilding the same toolchain in different environment.
(cherry picked from commit 83148fc5bb4e8bcc5afcf119df53ec1bc854be17)
Also improve an error message in `IrType.erasedUpperBound`, which seems
like a frequent first place where the JVM IR backend crashes in case an
error type has made it past psi2ir.
This will help in diagnosing problems such as KT-45016.
Because generateDefaultGetterBody/generateDefaultSetterBody reference
the property's backing field, which in case of extension properties
leads to an error "Unbound symbols not allowed" because extension
property cannot have a backing field.
In some way, this check is similar to the `isExpect` check in
`generatePrimaryConstructor`.
This has no effect on correct code because extension properties cannot
have a backing field anyway and that is checked separately. But this
function is used in psi2ir to determine whether or not to create a
backing field for a property, and in case the code where the property is
declared is unreachable like in KT-44496 and has no explicit getter or
setter, it would previously return true for extension properties, which
on JVM would result in an actual field in the class file, which made no
sense.
After this change, the compiler will actually crash with an exception in
the IR validaton step because the symbol for the field is unbound. That
is a bit better than proceeding to generate potentially invalid
bytecode, but of course a proper fix would be to report an error in the
frontend.
#KT-44496
Dmitriy Novozhilov