Default type of LazySubstitutingClassDescriptor is not lazy. However, most of default types are,
and there is an optimization in KotlinTypeFactory, which uses default type for simple type without
type arguments and/or annotations. LazySubstitutingClassDescriptor's default type creates simple type
with factory, which may therefore cause recursion.
#KT-34029 Fixed
Do this by reordering the lowerings so that the lowering that
adds continuations happen after default methods have been
eliminated if needed.
Mark more functions as known to be tail-calls: bridges and
delegated members.
Preserve source info and annotations when creating replacement
functions.
These fields were originally non-volatile because of an incorrect
assumption I had at the time that a value was safely published if the
underlying object's class has at least one final field. This is true for
almost all values used in lazy/lazySoft: DeserializedFunctionDescriptor,
DeserializedPropertyDescriptor, KTypeImpl, java.lang.reflect.Field, etc.
But of course, this only means that the object was _safely initialized_
and not safely published via the non-volatile reference, where other
threads can still observe null, even after that constructed object was
leaked to the outer world by some other means and led to observable
changes in behavior.
This can fix some concurrency issues in kotlin-reflect. I wasn't able to
reproduce the problem in stress tests though.
- Extract all backend codegen tests that specifically target behaviour
in to-be-deprecated functionality from language versions < 1.3"
- Remove those tests from the JVM IR test suite.
This commit fixes the 'KotlinAndroid32GradleIT.testKaptUsingApOptionProvidersAsNestedInputOutput()' test that started to fail after switching to the worker API mode by default.
IntelliJ doesn't call KotlinDebuggerEvaluator from Java contexts; instead, it calls JavaDebuggerEvaluator.
Unfortunately, there seems to be no way to figure out the exact evaluation type for Java contexts. However, we can at least log the evaluation status itself.
Before this commit, the substituted FunctionDescriptor didn't have a source element.
As a result, 'CodeFragmentParameterAnalyzer.isCodeFragmentDeclaration' failed to recognize such a descriptor as fragment-local, and it was erroneously captured.
It seems like it doesn't make much sense to create expression code fragments.
People type statements or several expressions separated with a semicolon to a single-line expression line.
That is exactly what block code fragment was designed for.
Alexander Udalov