Commit Graph

7 Commits

Author SHA1 Message Date
Kristoffer Andersen
6f8682c950 [JVM IR] Stabilize accesor names in IR Backend
- 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.
2019-12-02 08:19:52 +01:00
Kristoffer Andersen
d1c2862e27 IR: Align Interface Defaults with Old Backend
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.
2019-12-02 08:19:52 +01:00
Steven Schäfer
570ee38256 Implement special cases for the hashCode intrinsic in JVM_IR 2019-05-10 09:40:57 +02:00
Mads Ager
3a11322506 Enable bytecode text tests for the JVM_IR backend. 2018-12-21 16:20:45 +01:00
Alexander Udalov
f5ff3d2fa9 Remove directives that have no effect from bytecode text tests
All bytecode text tests are run with stdlib in the classpath and only
for JVM backend, therefore directives WITH_RUNTIME, TARGET_BACKEND,
IGNORE_BACKEND are not needed
2018-12-20 12:53:24 +01:00
Alexander Udalov
e3c381a298 Remove API_VERSION 1.3 from tests on JvmDefault
So that these tests will now check behavior on the latest API version
2018-12-20 12:53:23 +01:00
Mikhael Bogdanov
c6b4bae81f Move 'bytecodeText' java 8 tests to common 2018-10-23 16:27:50 +02:00