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
Previously initializing the DependencyProcessor will result in file IO.
In a fully-hermetic environment where all dependencies are local, this IO is redundant and may require the build system (e.g. Bazel) to do extra setup to ensure there is a local writable directory specified for these directories. This change will instead cause the dependency processor to bail early and skip downloading dependencies if all are local anyway.
Prior to this change kicking off a clean build with local dependencies would result in:
```
rm -rf ~/.konan/cache; fswatch -ax ~/.konan
~/.konan/cache Created IsDir
~/.konan/cache/.lock Created IsFile
```
After the change no FS operations are performed.
- Mangle names for extension receivers in lambdas
- Correctly mark anonymous variables and variables for arguments
for destructuring declaration.
There is one failure remaining which is cause by lambda
type inference differences that leads to FIR having an explicit
return from the lambda whereas old frontend leads to an implicit
return. This difference is visible in debug stepping that the
local variables tests do because the implicit return has the line
number of the closing brace of the lambda. This change adds an
IrText test to make the difference clear.
This is needed because now these tests use new test infrastructure
and here, after frontend facade, there is error check. We need to
disable such check in these tests.
Mikhail Glukhikh