After an accidental change in 846537b367, we started generating metadata
into anonymous classes for callable references. This metadata contained
the Kotlin representation of the referenced function. In KT-53794, this
led to a problem where Java's protected visibility could not be
represented in Kotlin terms, which crashed the backend.
But also, this metadata is useless because there's no real use case for
interpreting it (since you already have a function reference object at
runtime with all the needed information), so it would take some extra
space in the bytecode.
#KT-53794 Fixed
This test uses a hacky mode of the compiler which is not worth it to
support further (especially in K2), `USE_SINGLE_MODULE`, where
everything is compiled in one module. The purpose of the test is just to
check that metadata for local/anonymous classes is written correctly.
So we can replace it with the tests on kotlinp, which uses
kotlinx-metadata-jvm and dumps all loaded metadata to text.
This replacement is not perfect, in particular because it won't check
that the reflection machinery is able to load this metadata, and because
it won't check that annotations are loaded correctly from the bytecode.
But IMHO it's good enough, there are box tests on reflection on local
classes (e.g. `reflection/annotations/localClassLiteral.kt`), so this
way is better than having to support the weird compiler mode for just
one test.
It's reported on receivers in extension function calls with stub type,
as such calls can shadow members of finalized stub types causing
change of resolve when corresponding type argument specified explicitly
It works by checking extension receiver during call resolution parts run
That way we can easily detect if we found an extension applicable to
stub receiver and report call diagnostic for it
KT-53739
Let's call builder lambdas (BL) a lambda that has non-fixed input type
projection at the moment of lambda arguments analysis, such lambdas
is a subject to be analyzed with builder inference
Due to bug in constraint system joining algorithm, currently system
of two or more such lambdas may lead to unsound type inference
Diagnostic added here should be reported in case when there are two
BL that shares a common constraint system, while not annotated with
@BuilderInference, as a protection against aforementioned bug
It's reported by ConstraintSystemCompleter when such situation has
occurred during builder inference phase, it is the same place that
decides wherever lambdas is subject to builder inference or not
KT-53740
Dmitriy Novozhilov