Consider adding a static type of the receiver into the AST nodes for invocations

[alexmarkov]

functionType in the new invocation nodes such as InstanceInvocation doesn't include static type of the receiver.
VM uses static type of the receiver to do certain optimizations and stores it in the call site attributes metadata.
It would be much more convenient to include that information in the invocation nodes. Other back-ends might also benefit from having that information.

Example:

class A<T> {
  void foo(T arg) {}
}

class B<T> extends A<T> {}

class C extends A<int> {}

B<String> x = B<String>();

C y = C();

main() {
  x.foo('hi');
  y.foo(42);
}

Kernel:

  class A<T extends core::Object? = dynamic> extends core::Object {
    synthetic constructor •() → foo::A<foo::A::T%>
      : super core::Object::•()
      ;
    method foo(generic-covariant-impl foo::A::T% arg) → void {}
  }
  class B<T extends core::Object? = dynamic> extends foo::A<foo::B::T%> {
    synthetic constructor •() → foo::B<foo::B::T%>
      : super foo::A::•()
      ;
  }
  class C extends foo::A<core::int> {
    synthetic constructor •() → foo::C
      : super foo::A::•()
      ;
  }
  static field foo::B<core::String> x = new foo::B::•<core::String>();
  static field foo::C y = new foo::C::•();
  static method main() → dynamic {
    [@vm.call-site-attributes.metadata=receiverType:library file:///.../foo.dart::B<dart.core::String>] foo::x.{foo::A::foo}("hi"){(core::String) → void};
    [@vm.call-site-attributes.metadata=receiverType:library file:///.../foo.dart::C] foo::y.{foo::A::foo}(42){(core::int) → void};
  }

VM uses static type of the receiver (B<String>) in the first case to speculatively skip parameter type check if actual type at runtime matches static type. It also uses the fact that static type of the receiver (C) is non-generic in the 2nd case to skip type check.

@johnniwinther @mkustermann @mraleph

[mkustermann]

Just a side note:

I assume this information could be deduced when operating on Kernel ASTs in Dart and is therefore somewhat redundant. So it's effectively adding a cache to AST nodes. The VM has a hard time to re-compute this information, which is why we'd like to have it in the kernel binary.

If adding this information would increase RAM consumption / binary size without benefits for non-VM scenarios, then we could think about whether it would make sense to push this to the serialization layer: Tell the kernel binary writer whether it should (or shouldn't) include such information when writing out the bytes, if it should, it could compute it when serialising. This would avoid penalising other backends.