The commit removes all the KLib resolution logic,
now Analysis API Standalone clients need to provide all the KLib
list directly.
The resolution logic was removed as too error-prone and requiring compiler configurations.
Kotlin Gradle plugin can provide a full set of required KLibs,
so if a client is a Gradle plugin, this should not be an issue.
Probably, some fancy API which will explicitly perform all KLib dependency searches
should be introduced in the future (KT-63395)
^KT-63126 fixed
This change is required to support a new approach to lowering
execution. There will be no more guarantee that every module
will execute `JsDefaultArgumentStubGenerator` lowering before
moving on.
#KT-63073
There are a lot of cases when a DEF file for a K/N platform library
has incomplete set of dependencies in 'depends=' property in
the manifest file. This leads to use of "KLIB resolver" - the
component inside the compiler that is responsible for finding the
missing libraries and implicitly (i.e. invisibly for the end user)
adding them to the set of dependencies of the compiler invocation.
The goal of this commit is to fix 'depends=' in manifest files so that
they should reflect the REAL set of dependencies, and as a result don't
trigger use of "KLIB resolver". This way we could be more prepared to
removed in the "KLIB resolver" in the future.
^KT-61098
Synchronously copy system properties before iterating over them, because
other thread sometimes tries to modify them in the meantime, which leads
to ConcurrentModificationException otherwise.
Intercept decompiler calls to process files that belong to classpath
builtins from K2 IDE differently. Their content won't be filtered w.r.t.
JVM logic during decompilation.
Split stub versions for .kotlin_builtins with K1 and K2 IDE.
K2 currently uses a single shared symbol provider for builtins of all
platforms. KotlinBuiltInDecompiler filters out duplicated declarations
contained in JVM classfiles as required for K1. For K2 this logic
doesn't fit: non-JVM modules (common, in particular) rely on
.kotlin_builtins, because kotlin-stdlib-common doesn't contain
.kotlin_builtins or .knm files for some of the built-in declarations
(e.g., kotlin.Unit). IDE has to restore the missing declarations using
built-ins from classloader. Filtering declarations from there using K1
logic breaks resolution of these declarations inside common modules in
IDE. The change shouldn't affect JVM modules as are able to resolve
all builtin symbols from the standard library before falling back to
built-ins.
KT-61757
Add an ability to publish kotlin-native-compiler-embeddable.jar and
sources to maven. Adds necessary for that sourcesJar and javadocJar
tasks. Note that Native distribution uses this jar without a version postfix.
Also cleaned up the obsolete backend.native publication and renamed
project to match its name.
Merge-request: KT-MR-12974
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
In commit 4e89dcf, we have prepared the API for IC maps in top
interfaces and provide the implementation in abstract classes.
In this commit, we refactor IC maps so that they directly inherit/reuse
the implementation from the superclasses without having to reimplement
the APIs for a map.
Test: Existing tests (refactoring change)
^KT-63456: In progress
Authored-by: Hung Nguyen <hungnv@google.com>
Merge-request: KOTLIN-MR-801
Merged-by: Evgenii Mazhukin <evgenii.mazhukin@jetbrains.com>
Not all Kotlin disambiguation rules are required for non-MPP projects.
On the other hand, they lead to increased memory consumption in Gradle
daemon especially notable on big multimodule projects.
To address this memory increase, we start to apply these rules
conditionally based on the applied plugin.
^KT-63005 Fixed
On CI when populating build cache, the build runs
with --info logging level causing an additional jvm argument
provided to the task.
This argument is usually not provided in local builds.
The argument only affects task printout and not its outputs.
In certain situations like constructor calls, it's possible
to have different WasExperimental/SinceKotlin pairs associated
with one use-site, e.g. a constructor call is associated both
with a constructor declaration and a class declaration.
However, looks like it make no sense to handle this situation
in FirSinceKotlinHelpers, because FirOptInUsageBaseChecker already
handles them.
#KT-59825 Fixed
Ilya Kirillov