Exhaustiveness check should be able to prefer API instead of non-API witnesses

[scheglov]

See https://dart-review.googlesource.com/c/sdk/+/308520 for the initial question.

With this CL, if we write switch like this:

void f(TypedLiteral node) {
  switch (node) {
  }
}

...and use "Add missing case" twice, it does end up with using implementation classes.

void f(TypedLiteral node) {
  switch (node) {
    case ListLiteralImpl():
      // TODO: Handle this case.
    case SetOrMapLiteralImpl():
      // TODO: Handle this case.
  }
}

It does not have to, and this API version works as well.

void f(TypedLiteral node) {
  switch (node) {
    case ListLiteral():
      // TODO: Handle this case.
    case SetOrMapLiteral():
      // TODO: Handle this case.
  }
}

So, here we might have a tooling issue. Either CFE should be enhanced to prefer reporting witnesses that are available in the target code, maybe some filtering, etc. Or the quick fix should climb up. Ideologically, I think it should be CFE. Or the analyzer in a way how it feeds data into CFE, e.g. never return non-API classes that the target package should not use. Not different than how code completion will not suggest non-API classes from other packages.

[bwilkerson]

It appears that we do a better job than I expected. I don't have your CL patched in, but when I mark TypedLiteral as sealed and change the example slightly to force the switch to be exhaustive:

void f(TypedLiteral node) {
  var x = switch (node) {
    ListLiteral() => 2,
    SetOrMapLiteral() => 1,
  };
  print(x);
}

It realizes that those two types are supertypes of all of the subtypes of TypedLiteral and doesn't complain (which I thought it would).

I agree, though, that the tools need to do a better job with package-private types.