Kotlinc source’s file DescriptorUtils.kt demonstarted non-deterministic
insertion of checkExpressionValueIsNotNull for value returned by
CallableDescriptor::getOriginal(). It was difficult to reproduce
this behavior on ф smaller example, but I added a test which was
failing once in 5-10 times while I was testing manually.
I believe this bug is close to KT-23704.
This PR addresses non-determinism to a degree when I can run 120
Compilations with './gradlew dist' and get same classes in all
jars in 'dist'.
NOTE that thew fact that insertion of checkExpressionValueIsNotNull may
depend on order of the types seems suspicios. This CL only addresses
non-determinism part, but I believe it’s worth looking into this more
from semantics point of view.
`countDefaultParameters` uses `hasDefaultValue` to compute the number of
parameters which have default values, which handles actual parameters
(who have default values in the expected declaration) correctly. Thus,
`getRemainingParameters` should use it as well to determine the list of
parameters to be skipped in each generated overload
#KT-23910 Fixed
- 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
New sourceSet is created if it doesn't exist, instead of being silently ignored.
Fix receiver of `none()`: it was applied on sourceSetName rather than on the sourceSet,
therefore it was a no-operation.
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
Basically, it's unnecessary to check anything when analysing stubs,
but it's complicated now to avoid that, so we just postpone
computing AST until reporting happens
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
Alexander Udalov