Initially, it was added accidentally as part of e3f987459c
and missed all out processes.
Adding @SinceKotlin("1.7") after the annotation has already been
published before is not really a problem, because it only may be used
with an experimental `-Xcontext-receivers` flag, thus it doesn't have
to be a part of our regular backward compatibility routine.
^KT-55226 Fixed
Previously, a function reference that used generic parameters from its
outer scope was lowered into a top-level non-generic subclass of
`FunctionN`, with `FunctionN` type arguments referencing type parameters
not present in the scope anymore. This sometimes resulted in generating
malformed mangled names.
From now on the generated subclass of `FunctionN` is generic. The needed
type arguments are passed upon instantiation, when the relevant generic
parameters are present in the scope.
This requires plumbing a Fe10AnalysisContext through to the
KtFe10AnnotationsList, so that the context's module descriptor and
KotlinBuiltIns instance can be used to look up types correctly.
This eliminates the difference between the FIR and FE1.0 AA
implementations with regards to annotation spread argument handling.
This changes FirAnnotationValueConverter to no longer rely on PSI
information when projecting annotation parameter information to AA.
For annotations defined in Java, including many meta-annotations, PSI
information is not available for the annotation. This caused those
annotation values to be projected as KtUnsupportedAnnotationValue.
Instead of using PSI information, this changes
FirAnnotationValueConverter to use the tree structure instead. Spread
and named parameter arguments are spliced into the parameter list of
their surrounding vararg calls, meaning that callers see the expected
structure. (See the varargSpreadParameter.kt test file for an example.)
This test ensures that annotations on other annotations are properly
handled, even if those annotations are defined in Java rather than in
Kotlin.
Note that this functionality only works on FIR, and currently has bugs
that mean the result is an error type. Follow-on changes will fix the
error-type bug, and restore proper functionality for FIR.
CoreApplicationEnvironment.registerApplicationDynamicExtensionPoint should be
guarded to ensure registration won't happen concurrently
Merge-request: KT-MR-8251
Merged-by: Pavel Punegov <Pavel.Punegov@jetbrains.com>
When using correct error types and there is a property setter or
receiver for an unknown type then the parameter type would be `Object` instead
of the error type.
This fixes KT-46965 and KT-46966
Previously the annotations were included in reverse order. With this
change they are kept in the same order as in the source file.
This changes the test case for KT-23427 but that issue seems to relate
to annotation arguments that are missing, not the order of repeatable
annotations.
This fixes KT-51087
Dmitriy Novozhilov