Description
There's an ugly corner case in the front end's forwarding stub handling logic that we need to figure out how to handle properly. I'm calling it a "forwarding semi-stub". Consider the following code (adapted from pkg/front_end/testcases/runtime_checks_new/abstract_override_becomes_forwarding_stub.dart):
class B {
void f(num x) {}
}
abstract class I<T> {
void f(T x);
}
class C extends B implements I<num> {
void f(num x);
}From one point of view, C::f is not a forwarding stub, because it's an actual abstract method that appears in the user's source code; it's not inserted by the front end. This is the point of view that makes sense for the analyzer, since it cares only about what appears in the user's source code and doesn't need to know about runtime type checks.
From another point of view, C::f is a forwarding stub, because it's a place where a runtime type check needs to be inserted in order to ensure that the appropriate error is thrown when code like this is executed:
main() {
I<Object> i = new C();
i.f("oops");
}We need to decide how this should be represented in kernel. I will follow up with a comment with more information about how it is currently represented.
I will also add a language_2 test verifying that the correct type checks occur in this situation, as well as analyzer tests to make sure that the analyzer behaves correctly.