Unlike ordinary lambdas, suspend lambdas do the computation in
doResume(Ljava/lang/Object;Ljava/lang/Throwable;)Ljava/lang/Object;
method. As you can see, there are no decomposed parameters. As a result,
they used not to be generated.
To fix the issue, I add decomposed parameters to value parameters while
generating local variables table.
In addition, when generating suspend lambda for inline, the codegen
does not take this kind of parameters into account. This is also fixed.
#KT-18576: Fixed
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
Ilmir Usmanov