If it isn't ANNOTATION_CLASS, the newly added code in
`FunctionCodegen.isDeprecatedHidden` (0e91d3fcb0) ends up transforming
IR annotation constructor calls to annotation descriptors, and an
assertion fails in `IrBasedDeclarationDescriptor.toAnnotationDescriptor`
which checks that the class has kind ANNOTATION_CLASS.
Specifically, this failed in the JVM IR bootstrap on
`CallResolutionInterceptorExtension.interceptCandidates` from module
'frontend'.
We generate @java.lang.Deprecated annotation on methods of $DefaultImpls
classes in compatibility mode. This annotation has RUNTIME retention and
should be visible.
Also, get rid of representing annotations as Class'es (yes we know that
these annotations are in compiler CLASSPATH, but we should not rely on
such classes and associated information).
Before this commit we considered !isOverride as a sign that
function / field / accessor has no overridden symbols.
However, it's false for deserialized, because isOverride
is always false there.
This commit fixes 68 BB tests but breaks 25 BB tests (not yet muted)
The only case we may need fake override for private members is
a situation when class refers itself with different type arguments.
So in this commit we forbid such fake overrides when we can prove
that class does not refers itself here.
The first change here is swapping the isCompatibility and hasJvmDefault
checks. Otherwise behavior could be different depending on -Xjvm-default
mode even for non-JvmDefault declarations, which makes little sense.
Another change is avoiding generating $default stubs for fake overrides
in interfaces, which replicates the behavior of the current backend.
(Note that this change also fixes the first problem on the newly added
tests, but the first change seems useful anyway.)
Currently FirThisReceiverExpression of instance methods are translated
to references of the class' thisReceiver,
not the method's dispatch receiver,
which causes problems with IrFrameMap::typeOf,
as the class' thisReceiver is not in the typeMap.
This commit translates non-qualified "this" references of
instance methods to references of the methods' dispatch receiver.
Like the old backend, always leave private @JvmDefault annotated
interface members (properties, methods) on the interface, just like
the old backend. Fix naming, and introduce test to document the naming
scheme.
- introduce a scoped counter instead of a global one for name
generation for accessors. Naive solution not working.
- Introduced hardcoded "jd" suffix for accessors on interfaces, under
the assumption that the only such accessors are due to JvmDefault
and their bridges from `$DefaultImpls`. Removed all associated
templated tests, so the old and IR backend correspond on this matter
again.
- Respecialized writeFlags from regexps to string-equality: we are
going for exact matches now!
- Fixed package calculation in `IrUtils.kt`.
- Accessors for static members must be due to accessing super
classes. Actual super-qualified calls are naturally also accessing
super classes. Hence the `$s+{hashcode(superClassName)}`
suffix. Added test to affirm this naming scheme.
- Field getters/setters for static fields must be companion accessors,
otherwise just labelled as accessors. They are also tagged with `s`
suffix when accessing static fields.
- For naming of accessors to coincide with the old backend, field
renaming to avoid JVM signature clashes must be done _after_
generation of accessors for those fields.
Change the treatment of default implementations on interfaces in JVM
compatibility mode. Previously, the IR backend moved the actual
default implementation to the DefaultImpls class, and then bridged to
it from the interface default. The old backend did the reverse, at the
cost of an additional accessor, in order to gain better binary
compatibility properties. See #2612 for discussion.
The accessor needs to call a specific implementation, so must be
performed through an `invokespecial`. We trick the
SyntheticAccessorLowering into doing this for us, by marking the
bridging call as a super call. We do this in want of an explicit
`invokespecial` Ir Node.
InterfaceDefaultCallsPhase previously assumed the old behaviour of the
IR backend (that calls to default implementations, e.g. `foo$default`
should target `DefaultImpls.foo$default`). But now the bridge to
foo$default resides on `DefaultImpls` already, causing that pass to
create a recursive loop. We cut that loop with a simple check.
Mikhael Bogdanov