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
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.
- Application is null before setUp call in individual run
- Inline "module.info.add.requires.family.name" as 181 has other constant
- isScriptDependenciesUpdaterDisabled call seems to be useless
- Add more tests
- Fix inserting close quotes after multiline string in file end
- Use parent instead of parentOfType where possible
- Add bunch files
#KT-2582 Fixed
There is a single PartialBodyResolveFilter instance per module
and each of them were containing just the same sets of available
in project Nothing-typed functions (including duplicating String instances),
in case of Kotlin project it might sum up to 27M of heap.
The solution is to share the global sets between all modules in a project
Otherwise results are effectively retained in the maps until we're close
to OutOfMemory.
While we mostly need them for a short time (especially in the case we
run resolution during usages search).
The possible problem is that the values may become too short-living,
but now using these maps is a conventional solution for similar tasks in
Java resolve
Before this change, when somebody has requested the exact light class
we also store LazyJvmDiagnostic for it in a map inside DiagnosticHolder.
The problem is that LazyJvmDiagnostic retains a lot of memory:
GenerationState, bindingContext, etc.
At the same time, it commonly happens that light classes are being computed from Java resolve and diagnostics are obviously
unnecessary there.
The solution has two parts:
1. We don't retain diagnostics until somebody explicitly requested them
2. We force computation of LazyJvmDiagnostic to avoid retaining
backend's parts
The solution has a kind of drawback: for an opened in editor Kotlin file,
we'll run back-end twice for contained classes (analysis parts should be reused, though)
#KT-24048 Fixed
Natalia Selezneva