Analyzer fails to check exact types of set literal elements

[stereotype441]

Found by the following co19 tests:

• co19_2/LanguageFeatures/Set-literals/set_literals_A03_t01/03
• co19_2/LanguageFeatures/Set-literals/set_literals_A03_t01/04
• co19_2/LanguageFeatures/Set-literals/set_literals_A03_t02/01
• co19_2/LanguageFeatures/Set-literals/set_literals_A03_t02/02

Consider this example:

class A {
  const A();
}
class B extends A {
  const B();
}

main() {
  var x = <B>{new A()};
}

This should produce a compile-time error, because the exact type of new A() is known at compile time to be A, and A is not a subtype of B.

Note that the analyzer correctly implements the corresponding behavior for lists, e.g.:

class A {
  const A();
}
class B extends A {
  const B();
}

main() {
  var x = <B>[new A()];
}

[stereotype441]

On second thought, I'm considering this a P1 because it concerns a feature we want to ship very soon.

[bwilkerson]

I think I'm missing something. The current form of the specification (https://github.com/dart-lang/language/blob/master/accepted/future-releases/set-literals/feature-specification.md) says:

Let T be the explicit or inferred type argument to the type literal. It's a compile-time error if the static type of any element expression is not assignable to T.

But A is assignable to B, so why should this produce a diagnostic?

[kmillikin]

It isn't an error for that reason (an expression with static type A would not be such an error). However, new A() is exactly an A because A is not a factory constructor and so we statically know that the downcast will fail.

I'm not sure that the rules for exact types have gotten written into the spec (@eernstg ?)

co19_2/LanguageFeatures/Set-literals/set_literals_A03_t01/04 and co19_2/LanguageFeatures/Set-literals/set_literals_A03_t02/02 should also be an error because the downcast from A to B fails during constant evaluation.

[bwilkerson]

I'm not sure that the rules for exact types have gotten written into the spec

@eernstg More importantly, are they written anywhere so that I can know what needs to be implemented?

@stereotype441 Are these rules implemented anywhere else in analyzer, or is support for exact types something new (and hence orthogonal to set literals)?

[stereotype441]

@stereotype441 Are these rules implemented anywhere else in analyzer, or is support for exact types something new (and hence orthogonal to set literals)?

Did you notice this line from the bug report?

Note that the analyzer correctly implements the corresponding behavior for lists, e.g.:...

You could try running the example with lists, see what error is reported, and then place a breakpoint on the code that reports that error to see how it works.

[stereotype441]

co19_2/LanguageFeatures/Set-literals/set_literals_A03_t01/04 and co19_2/LanguageFeatures/Set-literals/set_literals_A03_t02/02 should also be an error because the downcast from A to B fails during constant evaluation.

Good point. It seems that the analyzer doesn't do this properly for any container types. I've tracked that as a separate bug in #35748.

[bwilkerson]

https://dart-review.googlesource.com/c/sdk/+/91166