This commit introduces notion of 'PerformanceManager' in CLI, suitable
for collecting performance metrics of the compiler. It:
- provides `notifyX{Started/Finished}` API, where 'X' is some
measurable event (previously there were just ad hoc manual time
measurements using System.nanoTime() and stuff)
- collects measurements, so that later they can be reported in an
appropriate way (previously measurements were reported immediately to
MessageCollector as plain strings)
- allows overriding to collect metrics, specific for just one target
platform compilation
Also, common logic of compiler performance statistics collection was
extracted from platform-compilers (K2JVMCompiler) to common classes
(CLICompiler), to allow other platform-compilers (e.g. K2JSCompiler)
re-use it.
Since we're not yet sure of the design of Experimental/UseExperimental,
we're making them "experimental" themselves in some sense, in that the
user is required to provide the magic argument
"-Xuse-experimental=kotlin.Experimental" to be allowed to use either
Experimental or UseExperimental. This is more convenient than the
previous approach of "-language-version 1.3
-Xskip-metadata-version-check" because it's simpler and does not cause
pre-release binaries to be produced
See https://github.com/Kotlin/KEEP/issues/95#issuecomment-383889404
Drop Experimental.changesMayBreak, Experimental.Impact, the concept of
signature/body usage, same module exemption. Make the majority of tests
single-module because there is now no difference in the checker between
usages from the same module or from another module
so ".kt" and ".java" files are not considered as scripts and quickly
filtered out, and for the other files the the checks are implemented
using sequences, mechanisms provided to supply script definitions
lazily, and script discovery is implemented using this mechanisms.
- add options to disable scripting plugin and standard script definition
- move standard definition adding logic into appropriate place
- fix logic of scripting plugin loading
- add standard script definition on the environment creation to
ensure compatibility with all usages
- fix testdata
- some minor fixes
Unlike ordinary lambdas, suspend lambdas do the computation in
doResume(Ljava/lang/Object;Ljava/lang/Throwable;)Ljava/lang/Object;
method. As you can see, there are no decomposed parameters. As a result,
they used not to be generated.
To fix the issue, I add decomposed parameters to value parameters while
generating local variables table.
In addition, when generating suspend lambda for inline, the codegen
does not take this kind of parameters into account. This is also fixed.
#KT-18576: Fixed
Kotlinc source’s file DescriptorUtils.kt demonstarted non-deterministic
insertion of checkExpressionValueIsNotNull for value returned by
CallableDescriptor::getOriginal(). It was difficult to reproduce
this behavior on ф smaller example, but I added a test which was
failing once in 5-10 times while I was testing manually.
I believe this bug is close to KT-23704.
This PR addresses non-determinism to a degree when I can run 120
Compilations with './gradlew dist' and get same classes in all
jars in 'dist'.
NOTE that thew fact that insertion of checkExpressionValueIsNotNull may
depend on order of the types seems suspicios. This CL only addresses
non-determinism part, but I believe it’s worth looking into this more
from semantics point of view.
Mikhail Zarechenskiy