Since it's not feasible to support annotated types in 1.6, we're making
this an explicit error in 1.6, so that typeOf can become stable and this
feature can be supported in the future without breaking changes to the
existing code.
Note that extension function types are a special case of annotated
types. A separate error is created for them just because the message
"annotated types are not supported" would be confusing, since such types
don't have explicit annotations in the source code.
#KT-29919
Otherwise an invalid type is constructed which causes kotlin-reflect to
crash, and stdlib implementation to render the type incorrectly. The
reason is that suspend functional types are not properly supported in
reflection. Once they are supported, this error can be removed.
#KT-47562
Such as:
- PackageFragmentProviders, and, in particular,
CompositePackageFragmentProviders
- JavaPackageFragments
- Scopes produced by those providers
The rationale is that a lot of frontend-facing bugs (like red code) are
easily recognizeable in resolution. But at that point you just see a
bunch of scopes, without meaningful toStrings, you don't know who has
produced them, and what's exactly wrong.
With this commit it should make debugging slightly easier: now at least
you'll be able to see that "this scope is a scope of package fragment
for foo.bar of module baz" and decide whether the declaration should or
should not have been resolved from such scope.
Add extension point for java descriptors
Add simple usage of this point to generate getter method
Add simple test infrastructure to test compilation with lombok plugin
KotlinJvmBinaryClass.AnnotationArrayArgumentVisitor didn't cover the
case when the element type is an Annotation. Therefore, when the
compiler read an array of annotations from JVM binary classes built from
Kotlin sources, it got an empty array regardless of what was written in
the bytecode.
For example, Foo.value below is read as an empty array when SomeClass
resides in another Kotlin module.
@Foo(
value = [Bar(1), Bar(2)]
)
class SomeClass
Using "JVM_1_8" always resulted in incorrect mapping of Kotlin
annotation targets to Java element types.
The change in AbstractKotlinRenderLogTest is needed because while
CliTraceHolder.module is technically a descriptor leak, it was never
detected by this test accidentally, because of the depth cutoff equal to
10, which started to not be enough after the minor refactoring of
replacing `Delegates.notNull` with `lateinit`.
Alexander Udalov