The call to `createTopLevel` instead of `create` (which creates
serializers for outer classes properly, with correct type parameter
contexts) caused MetadataSerializer to write type parameter metadata
incorrectly. For example, in the following case:
class A<E> {
inner class B<T, E> { ... }
}
A's type parameter E would get id 0, and B's type parameters T and E
would get ids 0 and 1. This is a problem because ids are supposed to be
unique for each class including its outer classes, and deserializer,
decompiler and stub builder rely on this assumption.
JVM metadata is unaffected because `create` is called correctly there,
see MemberCodegen#generateKotlinClassMetadataAnnotation
#KT-24944 Fixed
- support common modules metadata compilation under flag (it is not required since all common source roots are included transitively for now)
- introduce expect actual tracker in jps: move implementation from gradle to build-common
- support js incremental compilation: move implementation from gradle to build-common
since it causes numerous classloading issues. Using the wrapping types
and reload them in the proper context when needed.
Note: this version supports only classes, but the wrapping type could
be extended to support other types in the future.
+ numerous fixes related to proper loading and handling of the templates.
- 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
Perform command line argument preprocessing in the beginning of
parseCommandLineArguments, so that argfiles are expanded in all
scenarios, not just when the compiler is invoked via
K2{JVM,JS}Compiler.exec
if assertions mode is not LEGACY.
This is done since assertions can be disabled (in both compile time and
runtime) and thus, the data flow info is not reliable anymore.
#KT-24529: Fixed
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.
if gradle project is being built with JPS, the gradle scripting plugin
is passed in the plugin classpath. Since it is rebased on the embeddable
compiler, it hides expected plugin registrar signature, which leads to
the AbstractMethodError on attempt to load the plugin. Putting incoming
classpath at the end of the resulting one fixes the issue.
Fixes #KT-24448
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.
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
Alexander Podkhalyuzin