It is difficult to implement properly tail calls for a real coroutine (when there
are other non tail calls), because of continuation interception semantics. And the
benefits aren't clear at this point, so let's turn it off for now.
This commit fixes:
```
./gradlew :kotlin-native:backend.native:compileCompilerKotlin -PdeployVersion=1.9.0-dev-900
```
`-PdeployVersion=1.9.0-dev-900` is important for reproducibility (it's
not necessarily `1.9.0-dev-900` any version starting with `1.9.0-dev`
will reproduce the problem)
FunctionalTypeKind can be used in FE 1.0 too, so there is no need to
keep both classes. Also, removal of FunctionClassKind simplifies work
with FunctionalTypeKind in common code, like Analysis Api
Review: https://jetbrains.team/p/kt/reviews/8401
In scope of: KT-55082
Because this version isn't used for anything. We have KotlinAbiVersion
to version the IR format.
Review: https://jetbrains.team/p/kt/reviews/8401
- Code style
- Drop unused properties in kotlin-native/build.gradle
- kotlin-native/build.gradle: drop unused import
- use final instead of open when possible
This is just a cleanup commit. It neither fixes any issue/bug, nor
introduces new behaviour.
Feel free to revert this commit if you find out that it breaks something
Add debug information for inline function parameters
Previously during debugging Kotlin/Native applications you couldn't inspect the inline function or inline lambda parameters. This happened because the debug information for them wasn't generated at all. To fix this issue we have to store the information about which expressions were inlined instead of which parameters. This commit adds a new mapping, which allows storing the required information during the inlining phase. The mapping is then reused during the bitcode generation phase to add the debug information for inline function parameters.
^KT-55440
Starting from language version 1.9, deprecation is not propagated
through overrides (see KT-47902 for more details).
As a result, after updating langauge version to 1.9 in 66544a4,
testObjCExport started to fail, because it expected the old behaviour.
This commit updates the test correspondingly.
* Replace it with KotlinCompilerVersion
* K/N version should be set now with `deployVersion`.
* Cleanup deprecated functions in older versions
of the Gradle plugin
* Cleanup tests for older versions of compiler downloader
Merge-request: KT-MR-8436
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
This allows the compiler to limit imports from "magic" packages like
cnames.structs to forward declarations actually present in dependent
cinterop klibs.
The manifest already had `exportForwardDeclarations` field, but
- it didn't include Objective-C forward declarations (@class, @protocol)
- it has a slightly different meaning (the export list enables importing
the listed declarations through the interop package of the library,
while the include list shouldn't do that), so we better avoid mixing
them.
The test relies on the fact that any name can be imported from a "magic"
package like `objcnames.classes`.
This was the case for K1, but likely won't be for K2: the compiler
should allow importing only those names that are actually
forward-declared in a cinterop library.
This commit changes the test that way. In particular, moves it to a
different task that has a cinterop dependency.
Previous implementation set Nth ModuleDescriptor dependencies to the
first N modules. This is not always correct: for example, when producing
a metadata klib (-Xmetadata-klib) for HMPP, metadata dependencies might
have inexact or missing depends= in their manifests.
This commit sets ModuleDescriptor dependencies to all other
deserialized modules. The same approach is used for K1. That way, the
implementation is more reliable.
^KT-56071
Old implementation expected that builtIns should be based on a library
with no dependencies, usually stdlib. But that doesn't work properly in
some cases, e.g. when producing a metadata klib (-Xmetadata-klib) for
HMPP. In that case, some of the metadata dependencies can have no
depends= in the manifest, leading to the compiler choosing such a module
instead of stdlib.
This commit makes it look for a library that is explicitly stdlib
instead.
^KT-56071
There were still some cases where the generated function reference class
would contain references to generic parameters that were not in scope.
One example of that was `Array<*>::get`. Before this fix the generated
function reference class would still contain a reference to the
type parameter declared in the `Array` class.
Also, the logic of generifying the generated function reference class
was incorrect. For example, for function `fun <A, B> foo()` if we had
a reference `::foo<T, T>` (where `T` comes from the outer scope),
the class would still contain two generic parameter, despite that only
one generic parameter from the outer scope was referenced.
This is also fixed here.
The existing threshold for determining between medium and large page
does not take the dummy block into account, meaning that an allocation
on the threshold will lead to a loop that only terminates when the
process goes out of memory.
Co-authored-by: Troels Lund <troels@google.com>
Merge-request: KOTLIN-MR-618
Merged-by: Alexander Shabalin <alexander.shabalin@jetbrains.com>
Also introduce -Xsave-llvm-ir-directory argument
that should be used instead of -Xtemporary-files-dir
as a location for LLVM IR from phases.
Motivation for this change: it is simpler to implement
and unties LLVM actions from the awful TempFiles class.
In the new dynamic driver we have various contexts, inputs and outputs.
To make it possible to validate and dump IR uniformly, we need a couple
of adapter interfaces that will be accessed from phase actions.
It contains only commented CheckSamSuperTypes phase which is disabled
for quite some time. If we ever need this lowering again it could be
found in this commit.
Svyatoslav Scherbina