These properties have a very specific detail in their behavior, in that
the constructor's name is set to be "<init>". While this is OK for the
IR serialization, this may not always be expected in other cases, and
their rather common names (`name`, `fqNameSafe`) suggested that these
properties could be used in generic contexts.
Change all usages outside IR serialization to use
`IrDeclarationWithName.name` and nullable
`IrDeclarationWithName.fqNameWhenAvailable` instead
Although the intention of the change 9894c216c1 (#2341) was sensible, it
unfortunately caused the type mapper to map a default method incorrectly
under certain _undiscovered_ circumstances, which leads to incorrect
bytecode being generated. Specifically, this led to an exception:
java.lang.NoSuchMethodError : org.jetbrains.kotlin.idea.debugger.evaluate.KotlinDebuggerCaches$Companion.compileCodeFragmentCacheAware$default(Lorg/jetbrains/kotlin/psi/KtCodeFragment;Lcom/intellij/debugger/SourcePosition;Lkotlin/jvm/functions/Function0;ZILjava/lang/Object;)Lkotlin/Pair;
in a developer branch where this class was refactored and moved to
another module. I was not able to determine the exact reason of this
error, so I'm workarounding it by limiting this change to the IR backend
only (where it's needed), and postponing the investigation of the
failure above for now.
Before this commit, java.lang.Class was read via JvmBackendContext,
its module descriptor and its package member scope.
However, this works only for old FE with descriptors and
descriptor-based scopes available.
The synthesized arguments caused the size of default value mask off by
one when it is close to the boundary of Int.SIZE, which in turn
resulted in wrong signature at call sites.
The classes being filtered have been renamed months ago. The change
committed in KT-12402 is no longer relevant as the underlying issue has
been fixed.
Also that commit removes usages of builtins inside
effect system and starts refactoring of functor
composition via composition instead of inheritance.
There are some changes in testdata related to inference of recursive
functions with implicit return types.
After this commit they all are marked as unresolved. It happens because
those functions have DeferredType as return type, and computing this
type produces recursive exception, which provides “typechecker
recursive problem” diagnostic.
Before this commit, function call was completed successfully, because
call completer didn’t computed that type, and computation of DeferredType
were triggered only in `DataFlowAnalyzer.checkType`.
Now, effect system tries to compute that type while wrapping KotlinTypes
into ESTypes, and effect system itself is triggered in in call completer,
so, call completion doesn’t finish and function call is marked as unresolved.
#KT-31364
It breaks `org.jetbrains.kotlin.nj2k.NewJavaToKotlinConverterSingleFileTestGenerated.ToArray#testToArray` test due to losing external nullability annotations
Alexander Udalov