New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kernel representation of forwarding stubs is very inconvenient #31562

Closed
sjindel-google opened this Issue Dec 6, 2017 · 2 comments

Comments

3 participants
@sjindel-google
Contributor

sjindel-google commented Dec 6, 2017

Because they require special treatment, backends have to "pattern-match" against their bodies and compile them differently from other functions.

A representation more akin to redirecting factory constructors would make implementation easier.

@stereotype441

This comment has been minimized.

Show comment
Hide comment
@stereotype441

stereotype441 Dec 7, 2017

Member

This sounds like a nice way to address #31027 as well

Member

stereotype441 commented Dec 7, 2017

This sounds like a nice way to address #31027 as well

@stereotype441

This comment has been minimized.

Show comment
Hide comment
@stereotype441

stereotype441 Dec 7, 2017

Member

Note to whoever is implementing this: there are two things one might mean by the "target" of a forwarding stub:

  1. The interface target that would have been used had the forwarding stub not been present. I call this the "interface target" of the forwarding stub. Error messages based on static type analysis should use this target. The analyzer should use this target for "go to definition".
  2. The method that the forwarding stub forwards to at runtime. I call this the "super target" of the forwarding stub, since it is always in the superclass chain. The VM, dart2js, and DDC should use this target to determine which method the forwarding stub should invoke at runtime, and which types should be used for type checking.

Consider:

class A {
  void f(int x) { ... }
}
abstract class I {
  void f(covariant Object x);
}
class B extends A implements I {}

B will contain a forwarding stub for f. Its interface target is I::f. Its super target is A::f.

The target the VM cares about is the super target, and we already have a different bug about the interface target (#31519). So let's say that for the purpose of this bug, the representation we need is one that makes it easy for the back end to find the super target.

Member

stereotype441 commented Dec 7, 2017

Note to whoever is implementing this: there are two things one might mean by the "target" of a forwarding stub:

  1. The interface target that would have been used had the forwarding stub not been present. I call this the "interface target" of the forwarding stub. Error messages based on static type analysis should use this target. The analyzer should use this target for "go to definition".
  2. The method that the forwarding stub forwards to at runtime. I call this the "super target" of the forwarding stub, since it is always in the superclass chain. The VM, dart2js, and DDC should use this target to determine which method the forwarding stub should invoke at runtime, and which types should be used for type checking.

Consider:

class A {
  void f(int x) { ... }
}
abstract class I {
  void f(covariant Object x);
}
class B extends A implements I {}

B will contain a forwarding stub for f. Its interface target is I::f. Its super target is A::f.

The target the VM cares about is the super target, and we already have a different bug about the interface target (#31519). So let's say that for the purpose of this bug, the representation we need is one that makes it easy for the back end to find the super target.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment