- treat a contiguous whitespace sequence as a single argument separator,
not as several empty-string arguments separated by whitespaces
- fix infinite loop when reading unfinished quoted argument
- do not attempt to perform escape if the backslash is the last
character in the file
Previously, assert was just a regular function and its argument used to
be computed on each call (even if assertions are disabled on JVM).
This change adds support for 3 new behaviours of assert:
* always-enable (independently from -ea on JVM)
* always-disable (independently from -ea JVM)
* runtime/jvm (compile the calls like javac generates assert-operator)
* legacy (leave current eager semantics) - this already existed
Default behaviour is legacy for now.
The behavior is changed based on -Xassertions flag.
#KT-7540: Fixed
Arguments are passed in form '-XXLanguage:+LanguageFeatureName' for enabling
LanguageFeature.LanguageFeatureName, and '-XXLanguage:-LanguageFeatureName'
for disabling.
Note that they do override other settings, including 'language-version'
or extra ('-X') args.
In this mode, instead of analyzing files and generating bytecode for
them, compiler just saves imports of each file in JSON map of form
'<path to file> -> [<import1>, <import2>, ...]'
It is needed for some external tools, notably for Google3 toolchain.
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
- 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
- Use direct access to property defined into companion object when
it is possible rather than always use an accessor to access the
property.
- Use direct access will speedup runtime performance.
- Avoid to generate useless accessors for companion properties.
Fix of https://youtrack.jetbrains.com/issue/KT-14258
- Introduce new language feature 'ReadDeserializedContracts', which
allows to deserialize contracts from metadata.
- Introduce new language feature 'AllowContractsForCustomFunctions',
which allows reading contracts from sources.
- Use new features instead of combination 'CallsInPlaceEffect ||
ReturnsEffect'
- Rename 'CallsInPlaceEffect' -> 'UseCallsInPlaceEffect',
'ReturnsEffect' -> 'UseReturnsEffect'. As names suggest, they control
if it is allowed to use corresponding effect in analysis.
We have to introduce separate 'ReadDeserializedContracts' to enable
contracts only in some modules of the project, because libraries are
read with project-wide settings (see KT-20692).
*.kjsm and other files might be received when FileCollection is
used in Gradle as a dependency.
Example: `testCompile project(":$coroutines_core").sourceSets.test.output`
(a popular-ish solution to introduce dependencies between tests)
It's implemented through Jsr305State while it's not related
to jsr-305 becasue currently it's the most convenient way
to introduce the flag.
Probably, it's worth renaming Jsr305State to something more abstract
like NullabilityAnnotationsConfiguration
#KT-21982 Fixed
Dmitry Savvinov