There is no way to fix this in the source.

class TearOffClosure is a magical implementation class. It is a concrete class and it does have a 'call' method, but call method is programatically defined in ways that cannot be expressed in Dart.

You can't add a definition of 'call' since TearOffClosure can implement any signature, and different instances will implement different signatures. The one you try to define will be wrong.

This is another case where if we want the benefits of dartanalyzer in this library we need a mechanism to tell dartanalyzer which parts have apparent errors and warnings as a consequence of low level implementation details.

cc @bwilkerson.

Should we consider using external/patch to pull this (problematic) code in?

At first sight it would seem that the 'call' method could be declared as 'external'.
However, there is no syntax for declaring a method that may have any signature.

TearOffClosure #­1 might implement
   void call([a = 0]);
TearOffClosure #­2 might implement
   bool call(b, {c: true});

There is no way to declare a call method that covers both possibilities:

class TearOffClosure implements Closure {
  external call( ?? what goes here?? );
}

Even if we could express combined positional and named optional arguments, the alphabet of parameter names is a function of the whole application.

I'm not sure how patch is supposed to help - the result of merging a patch is supposed to be a valid class in the patch's context.

Fundamentally, this code is doing something that cannot be expressed in the language.

If I declare a call method, I get extra generated code and the TearOffClosures accidentally implement the chosen signature. I can make the implementation call noSuchMethod, but that adds about 10k of code and causes widespread code quality issues related to the type analysis precision costs of noSuchMethod. This is a very high price to pay for suppressing a couple of warnings.

Closing because this bug is not fixable currently.