No error in analyzer when tearing off a call method of a generic function type

[sgrekhov]

The following test produces an errors in CFE but has no issues in CFE

// SharedOptions=--enable-experiment=constructor-tearoffs

T foo1<T>(T value) => value;

main() {
  var funcValue1 = foo1;
  int Function(int) f1 = funcValue1.call;
//                                  ^^^^
// [analyzer] unspecified
// [cfe] unspecified

  T foo2<T>(T value) => value;
  var funcValue2 = foo2;
  int Function(int) f2 = funcValue2.call;
//                                  ^^^^
// [analyzer] unspecified
// [cfe] unspecified
}

According to the spec it must be an error

Tested on Dart SDK version: 2.15.0-edge.b2b8e59b2863ef02709dfdb750e9ae8e3732389c (be) (Fri Aug 13 01:08:51 2021 +0000) on "windows_x64"

[srawlins]

Similar to #46590; which should probably be fixed first, or simultaneously.

[eernstg]

I'm afraid this rule is getting reversed: The language team queried the CFE and backend teams about the need to have the restriction that "we can't perform a generic instantiation on an existing function object" (we've had this rule in the specification for years, but implementations did not enforce it consistently). It turns out to be unnecessary, so we are working on removing that restriction. Cf. dart-lang/language#1812.

I think this is a useful change, we're removing a limitation which was conceptually unjustified (surprising, and based on implementation considerations), and now those implementation considerations turn out to be irrelevant after all. So we might as well just remove the limitation.

@scheglov, I'm sorry about this — I know you have been doing work on the analyzer recently in order to ensure that an error is reported in a similar situation, but it will very likely (that is, if and when that PR 1812 lands) need to be changed back such that generic instantiation is allowed on expressions with a generic function type, not just expressions that statically resolve to a function/method declaration.

[eernstg]

I'll close this issue because we expect that said error is going away, so it would be a waste of time to implement that it is detected and reported.