Instead of a Boolean flag -Xserialize-ir, use modes: none,inline,all.
In "inline" mode, only information needed to deserialize bodies of inline
functions is serialized.
In the "all" mode, all declarations are serialized completely.
It's only enabled by default in FIR and might be turned on with a CLI flag
The main idea is that default FarFS re-read ZIP file list each time when
class file is requested that is quite slow.
We read it once and them reading bytes from the known offset.
Also, unlike the default version we don't perform attributes check on each access
On the one hand, it works faster on the other it might not notice that one
of the JAR has been changed during compilation process
But looks like it's not supposed to be a frequent even during
compilation of a single module
Instead of requiring it to be on the compiler classpath.
This will make it much easier to profile the Kotlin compiler daemon in
Gradle, by just specifying a compiler argument instead of also manually
patching the compiler jar.
Starting from language version 1.5, JVM IR is enabled by default, so
this option has no effect. To rollback to the old JVM backend, the new
option useOldBackend can be used.
#KT-45504 Fixed
Add -X flag to report extra compiler diagnostics which migth break compatibility.
Use the flag to unconditionally check constructors without fear of
prematurely evaluating lazy supertypes.
KT-19234
KT-42404
KT-44583
To be used in the project after bootstrap to get rid of warnings like
"Language version 1.3 is deprecated, ..." which prevent us from enabling
`-Werror` in `:compiler:cli` and other modules.
As soon as JVM IR is enabled by default (in language version 1.5), use
the CLI argument `-Xuse-old-backend` or Gradle option `useOldBackend` to
switch to the old JVM backend.
This flag was added a long time ago, at the time when we weren't sure if
we were going to keep the naming of local and anonymous classes
completely equal to the naming in the old backend. Now that we've
decided that we won't keep it equal and there are a lot of differences
already, it's not useful anymore.
- Use a more generic `-Xallow-unstable-dependencies` instead of
`-Xallow-jvm-ir-dependencies`
- Change `-Xir-binary-with-stable-abi` to `-Xabi-stability=stable`, with
an additional option to specify `unstable` after a subsequent commit
where JVM IR becomes stable by default
#KT-43592
This helps to reduce peak memory in lowerings/codegen by a lot.
A more robust approach would be to have a separate BindingContext for
each file, and clear each of them after running psi2ir on it. This would
also lower peak memory usage in psi2ir.
Provide a fallback workaround compiler argument
-Xir-do-not-clear-binding-context just in case BindingContext is in fact
used somewhere and it's not caught by tests.
Mikhael Bogdanov