If a declaration is annotated both with SinceKotlin and WasExperimental
and the SinceKotlin version makes it inaccessible, the experimental
checker must regard it as experimental, with markers specified in the
WasExperimental annotation arguments. So only errors/warnings about the
experimentality are going to be reported in this case, and no error that
the declaration is unavailable because of a low API version
For example, if a class is `@SinceKotlin("X")
@WasExperimental(M::class)`, then its constructor should also be
accessible if API < X, provided that the opt-in to M is given
Experimental and UseExperimental can only be used as annotations or
qualifiers (to allow "Experimental.Level.*"); experimental markers can
only be used as annotations or qualifiers, or as left-hand side of a
::class literal in arguments to UseExperimental/WasExperimental.
This is needed because we're not yet sure of the design of this feature
and would like to retain the possibility to drop these declarations
(Experimental, UseExperimental) altogether. If they were going to be
used as types, it would be problematic because we can't simply delete
something from stdlib, should deprecate it first. With this change,
these declarations can only be used if the user has opted into using the
experimental API somehow (for example, with
`-Xuse-experimental=kotlin.Experimental`), so we won't stop conforming
to our deprecation policy if we decide to remove these declarations in
the future
Usages of declarations annotated with WasExperimental are allowed even
if the API version requirement is not satisfied, provided that the
opt-in to all mentioned markers is given. This is needed for smooth
graduation of API in kotlin-stdlib
Since the custom source sets may be added after the plugins are applied in both common and platform module, we need to handle `.all { ... }` source sets in both modules and add common sources to the platform module once a match is found.
Issue #KT-22510 Fixed
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
Mikhail Zarechenskiy