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
pyos