1. Move jsInteropFunctionsLowering after callable reference lowering,
so it can continue to deal with just functions and function calls.
2. Generate lowered closure class in JsInteropFunctionsLowering because
They were added in e4702bf438 and a08cf59017 but in fact they are not
needed on JVM until there are JVM-specific extensions in the metadata.
Moreover, there was a typo in JvmValueParameterExtensionVisitor's
superclass (see https://github.com/JetBrains/kotlin/pull/4613).
^KT-48816 Fixed
Native compiler uses lazy IR for declarations provided by cinterop.
The problem: `FakeOverrideBuilder` requests super types during
type checking, accessing `.owner` for them. So if a type and super type
are represented as lazy IR, and lazy IR generation is not enabled yet,
then the super type symbol won't be bound by this moment, and the access
will fail.
This happens in KT-48816: fake override builder tries to access `.owner`
for `IrClassSymbol` of `NSObject` (super type of `NSDate` and `NSUUID`).
Fix this by enabling lazy IR generation before building fake overrides.
This shows up in annotation instantiation tests where we need
to make sure to generate a property on the annotation implementation
class for such properties.
This artifact was used to build compiler artifact during each project
build, which is not needed for running compiler tests. Removal of
this artifact from build chain reduces time of build for ~3 seconds
which is a lot for rebuilds after minor changes (which are usually
take only few seconds)
This convention seems to be more robust against clashes against user
specified source set names. We could potentially foresee users to
use "cinterop" as source set name, but the pattern
$sourceSetName-cinterop seems robust enough.
^KT-49596 Verification Pending
- Also increase the KotlinProjectStructureMetadata's format
version to 0.3.2
- Move new default location into /cinterop/{sourceSetName}
^KT-49596 Verification Pending
... and the compiler argument -Xskip-runtime-version-check.
The vast majority of warnings reported by this checker in practice has
proven to be false positives. In addition to that, it was needlessly
verbose, and also completely untested.
If we decide to reintroduce some of these checks, it's probably a better
idea to perform them in tools, such as Kotlin Gradle plugin, which
usually have slightly more information about the way the project is
built and can suggest some meaningful solutions (as opposed to "remove
this jar $HOME/.gradle/... from the classpath" which was the best
JvmRuntimeVersionsConsistencyChecker could do.)
#KT-27256 Obsolete
#KT-41664 Fixed
There are number of problems with up-to-date checks in tests, leading to
a test binary not being rebuilt or rerun when a developer expects it to.
Things became worse after updating to Gradle 7+:
test binary run tasks are considered up-to-date if the test data
has been changed, even after clean.
Even before Gradle 7+, we've observed other similar undesirable effects:
for example, if the compiler has been changed, tasks building
test binaries are still up-to-date.
There are quite a lot of different tasks related to running the tests
for Native, many of them are misused and thus don't do what we expect.
Carefully fixing each particular kind seems counterproductive and
unreliable.
So instead workaround all possible similar problems by forcing all tasks
in the :kotlin-native:backend.native:tests project to be not up-to-date.
This project should contain only test tasks, so this workaround
seems pretty natural -- it is just "tests aren't up-to-date".
This is faster than the current approach which creates
`JavaClassDescriptor`s, converts them to protos, and then snapshots
these protos.
- Refactor unit tests to faciliate further changes
- moves test data to a directory that matches the tests' package name
- moves expected snapshots to a separate directory
- adds public and private fields/properties to sample class
- Compute changes between ASM-based Java class snapshots
- Don't collect members of an added Java class as changes
as it's enough to report the name of the added Java class as changed (we
also do that for added Kotlin classes and Kotlin/Java removed classes).
- Add unit tests for impact analysis in advance
- Compute impacted symbols of changed symbols
Also do not collect added classes/class members as they don't impact
recompilation.
-Use ClassId when computing Java class changes
It is more precise than JvmClassName, which can be ambiguous around the
`$` character (e.g., ClassId "com/example/A$B.C" and "com/example/A.B$C"
both have the same JvmClassName "com/example/A$B$C").
- Compute impacted set of changed symbols across Kotlin and Java
- Add unit tests for impact analysis across Kotlin and Java
- Compute supertypes of Kotlin classes during snapshotting
- Handle inner classes when computing list of changed symbols.
For the reported symbols, always check all options:
class member, inner class, top level class, top level member.
Test: IncrementalJavaChangeClasspathSnapshotIT.testAddingInnerClass
In general, we would rather prefer a range-based for loop to look like
a counter loop in Java ('for (i = start; i < end; ++i) { <BODY> }').
This corresponds to
i = start;
do {
if (i >= end) break;
<BODY>
} while ( { ++i; true } )
However, HotSpot doesn't recognize Kotlin unsigned integer comparison
in 'if (i >= end) break;' as a counter loop condition. Thus, the loop
doesn't get optimized as a counter loop, resulting in a performance
regression.
If we use exclusive range-based for loop instead, then we actually use
unsigned integer equality instead of unsigned integer comparison, which
is Ok for HotSpot.
KT-49444
Svyatoslav Kuzmich