This is related to 8308f5d7d3 (KT-44977).
It turns out that it's necessary to create `ArrayValue` with a
precomputed type not only in case of annotations stored directly in
Kotlin metadata (i.e. annotations on types and type parameters), but
also for arguments of repeated annotations. The reason is that repeated
annotations are stored in an array themselves, as an argument to another
(container) annotation. The annotation-reading code unwraps this array
to load repeated annotations as individual instances of
`AnnotationDescriptor`, but in contrast to loading normal annotations,
it doesn't set `source` to the reflection object, it uses `NO_SOURCE`
(see BinaryClassAnnotationAndConstantLoaderImpl.AbstractAnnotationArgumentVisitor.visitArray).
So when kotlin-reflect is later asked for the arguments of the
annotation, it needs to recreate the reflection object from
`AnnotationDescriptor` in `util.kt`. Doing so requires knowing the array
type, which is now present because we're creating a `TypedArrayValue`
(previously `DeserializedArrayValue`) in places where arrays are read as
annotation arguments.
Alternative solution would be to fix source passed to
`AnnotationDescriptorImpl` in the annotation-reading code, but that
seems a bit messy because the code is very abstract and is used in lots
of other places.
#KT-53279 Fixed
Handling try/catch and break/continue is too hard here, and failing to
do that properly can create incorrect smartcast. Better be conservative
and assume all code is live.
When a looping control structure has a reassignment with an explicit
receiver, we don't need to erase its smartcast info as it has to be a
non-local property and is thus automatically unstable anyway. However,
we should still do that upon reaching the assignment itself for slightly
more precise error messages (as the property not just "could be"
reassigned, but *has been* reassigned already).
[IR] Remove unused MFVC getters
Signed-off-by: Evgeniy.Zhelenskiy <Evgeniy.Zhelenskiy@jetbrains.com>
#KT-1179
[IR] Add context receivers test, fix a flattening fields bug
Signed-off-by: Evgeniy.Zhelenskiy <Evgeniy.Zhelenskiy@jetbrains.com>
#KT-1179
[IR] Support `try` for MFVC
#KT-1179
[IR] Support `if` and `when` for MFVC, fix several bugs, refactor
#KT-1179
[IR] Rename MFVC tests + Add test for get-field optimization
#KT-1179
[IR] Suppress temporary test failing on Android
Bug is fixed in https://jetbrains.team/p/kt/reviews/6452
#KT-1179
[IR] Document the new MFVC lowering classes when necessary
#KT-1179
[IR] Correct work of the new MFVC lowering classes
#KT-1179
[IR] Prepare MFVC-lowering for the new MFVC classes
#KT-1179
[IR] Fix MFVC with type arguments/parameters
#KT-1179
[IR] Support MFVC with type parameters
#KT-1179
[IR] Integrate MFVC with Inline classes
#KT-1179
[IR] Fix compilation of MFVC in different module
#KT-1179
[IR] Add MFVC generation tests
#KT-1179
[IR] Implement equals call correct generation for MFVC
#KT-1179
[IR] Implement bridges generation for MFVC
#KT-1179
[IR] Implement MFVC basic flattening
#KT-1179
Merge-request: KT-MR-6213
Merged-by: Evgeniy Zhelenskiy <Evgeniy.Zhelenskiy@jetbrains.com>
* Add fallible push to intrusive_forward_list.
* Add fallible pop to intrusive_forward_list.
* Get rid of size_ member in intrusive_forward_list.
* Force all intrusive_forward_list items to have non-null next().
* Get rid of explicit colors in STMS and CMS.
* Do not queue weak reference for later processing in Mark.
Merge-request: KT-MR-7263
Merged-by: Alexander Shabalin <Alexander.Shabalin@jetbrains.com>
For some reason TARGET_JVM_VERSION_ATTRIBUTE was not always set in the
resulting artifacts for runtimeElementsConfigurationName and
apiElementsConfigurationName variants
It could be reproduced locally with by executing
`gradle kotlin-allopen:publishToMavenLocal`
The fix can be checked via
`gradle kotlin-allopen:outgoingVariants`
^KTI-920 Fixed
We want to move from current compilation pipeline
that is defined in TopLevelPhases.kt to a "dynamic" one.
The main drawback of the current one is that it is built
around single Context, single IR module, single compiler output, etc.
It is now as flexible as Kotlin/Native compiler requires.
For example, it is pretty hard to support multiple Apple frameworks
or a proper separate compilation.
To mitigate this problem, we are going to move to a new "dynamic"
compiler pipeline that relies on an explicit data passing between
different compiler phases. For example, it allows to use single phase
output as an input for multiple independent subsequent phases. Or
vice versa, e.g. use outputs of multiple "produce object file" phases by
a single linker phase.
This commit introduces `CompilerDriver` hierarchy which is required
during transition period.
A ModuleDescriptor is needed to create external package fragments with
descriptors (see JvmSymbols.kt). Descriptorless external package
fragments can fail in code using obsolete descriptor based APIs.
Makes build be able to publish bundles to the maven. It uses common
properties and settings as all other Kotlin publications.
Add usage of the Gradle base plugin and correct version and name setting
for archive tasks
Usage of this function is unsafe because it does not have native compiler
support. This means that compiler won't report UNCHECKED_CAST,
CAST_NEVER_SUCCEED or similar diagnostics in case of error cast
(which can happen immediately or after some refactoring of class hierarchy)
E.g. when substituting T -> Array<T>, write the bytecode for the
Array<...> part for typeOf.
This fixes various issues where either Array nesting levels, nullability
information (for typeOf), or entire reification markers were missing,
causing incorrect outputs ranging from missing `?`s to missing `[]`s to
just reified types not really being reified.
^KT-53761 Fixed
After introducing watchOsDeviceArm64 target it conflicted with existing
watchOsArm64 target. Because both having the same Konan Architecture as
Arm64. This is not entirely correct and actual
architectures are different. So it requires more precise macros for
fat framework.
* __ARM64_ARCH_8_32__ for `watchOsArm64` which is based on `arm64_32`
* __ARM64_ARCH_8__ for other arm64 devices including `watchOsDeviceArm64`
^KT-53107
Evgeniy.Zhelenskiy