The call to `createTopLevel` instead of `create` (which creates
serializers for outer classes properly, with correct type parameter
contexts) caused MetadataSerializer to write type parameter metadata
incorrectly. For example, in the following case:
class A<E> {
inner class B<T, E> { ... }
}
A's type parameter E would get id 0, and B's type parameters T and E
would get ids 0 and 1. This is a problem because ids are supposed to be
unique for each class including its outer classes, and deserializer,
decompiler and stub builder rely on this assumption.
JVM metadata is unaffected because `create` is called correctly there,
see MemberCodegen#generateKotlinClassMetadataAnnotation
#KT-24944 Fixed
so ".kt" and ".java" files are not considered as scripts and quickly
filtered out, and for the other files the the checks are implemented
using sequences, mechanisms provided to supply script definitions
lazily, and script discovery is implemented using this mechanisms.
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
It's very useful for Spring users because KotlinAnnotatedElementsSearcher
calls PsiBasedClassResolver::canBeTargetReference rather frequently
on a file and the latter function retreives importedFqName for each
import in the file that becomes a problem because computing fq-name
from PSI is a heavy computation
#KT-23380 In Progress
Affected cases:
- return type for suspend lambda
- aliased type in type alias declaration
- using type alias instead of aliased type in declarations
#KT-23345 Fixed
#KT-21696 Fixed
The problem is coming from the fact that `AnnotationTarget.VALUE_PARAMETER` is mapped to receiver parameter and to value parameter, but annotation with use-site target `receiver` can be used only on type reference of receiver parameter
Mikhail Zarechenskiy