Confusing follow-on errors when a const makes explicit use of a type parameter

[stereotype441]

Related to #33439, sometimes the analyzer produces strange and surprising follow-on errors when a const makes explicit use of a type parameter. For example, consider this code from the regression test for #26141:

abstract class Equality<R> {}
abstract class EqualityBase<R> implements Equality<R> {
  final C<R> c = const C<R>(); // (1)
  const EqualityBase();
}
class DefaultEquality<S> extends EqualityBase<S> {
  const DefaultEquality();
}
class SetEquality<T> implements Equality<T> {
  final Equality<T> field = const DefaultEquality<T>(); // (2)
  const SetEquality([Equality<T> inner = const DefaultEquality<T>()]); // (3)
}
class C<Q> {
  final List<Q> list = const <Q>[]; // (4)
  final Map<Q, Iterable<Q>> m =  const <Q, Iterable<Q>>{}; // (5)
  const C();
}
main() {
  const SetEquality<String>();
}

This code is invalid due to the fact that it makes use of type parameters in const expressions at (1), (2), (3), (4), and (5). Those errors are not reported due to #33439. I will shortly be publishing a CL that causes the analyzer to print the following results when analyzing this code in strong mode:

• A value of type 'List<Q>' can't be assigned to the field 'list', which has type 'List<R> (at (1))
• Evaluation of this constant expression throws an exception (at (2))
• Evaluation of this constant expression throws an exception (at (3))
• Evaluation of this constant expression throws an exception (at (5))

Note: these are currently reported as info rather than error due to one of the root causes of #33304. Once that is fixed, and #33439 is fixed, they will show up as follow-on errors, making it more difficult for the user to figure out what the actual problem is. It would be far better if, once the analyzer detects an incorrect use of a type parameter in a const expression, it would recover by taking the least closure of the invalid type (similar to what it should do when the types are inferred--see #32918). That should prevent any follow-on errors from being reported.

[srawlins]

This is unchanged.

[kallentu]

Evaluation of this constant expression throws an exceptions now have context messages that describe what the issue is. And there's two of them produced on the example above with relevant messages.

Then all the other errors are pretty clear and talk about not having type parameters at each const expression.

Closing -- the errors seem clear and are able to lead users to figure out what the issue is with their const usage.