You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During Dart 2.0 test migration, it became evident that the test type_variable_bounds4_test.dart (which currently exists in language and language_strong and will soon exist in language_2) uses a multi-test logic which is too weak: It surely intends to check that about 10 different situations cause a compile-time error (a static type warning in Dart 1.x), but it will in fact succeed as long as any non-empty subset of them causes an error. In other words, we might fail to have 9 out of 10 expected errors, and nobody would notice. The test needs to use a different multi-test logic such that each error is checked separately.
Here's some code that has nothing to do with the actual test, but which shows the core of the issue:
main() {
// Let's say we think this should be flagged as an error.int x =42; //# 01: compile-time error// We also think this should be flagged as an error.
x = x +1; //# 01: continued// ... somewhere in the middle, we have a real error.
by the way, here's a real error. //# 01: continued}
The intention is that each line marked with //# 01: .. should be flagged as an error, but the effect is that this test succeeds because a non-empty subset of the marked lines actually contains an error. The following would work:
main() {
// This declaration is expected to cause several usages to incur a compile-time error.int x =42;
x = x +1; //# 01: compile-time error
by the way, here's a real error. //# 02: compile-time error}
We would then notice that there is no error for x = x + 1, as we should.
We have about 2558 occurrences of continued in test files under tests; it is not obvious whether this is a single exception or the issue may affect several tests.
The text was updated successfully, but these errors were encountered:
eernstg
added
the
area-test
Cross-cutting test issues (use area- labels for specific failures; not used for package:test).
label
Sep 8, 2017
Note that test files containing multiple occurrences of /*@compile-error=unspecified*/ use the same (faulty) logic: If just one compile-time error occurs then the complete test run is considered successful, even though we may have just one actual compile-time error, and all the others are free-riders. As of Feb 2018, the following test files in tests/language_2 have this problem:
During Dart 2.0 test migration, it became evident that the test
type_variable_bounds4_test.dart
(which currently exists inlanguage
andlanguage_strong
and will soon exist inlanguage_2
) uses a multi-test logic which is too weak: It surely intends to check that about 10 different situations cause a compile-time error (a static type warning in Dart 1.x), but it will in fact succeed as long as any non-empty subset of them causes an error. In other words, we might fail to have 9 out of 10 expected errors, and nobody would notice. The test needs to use a different multi-test logic such that each error is checked separately.Here's some code that has nothing to do with the actual test, but which shows the core of the issue:
The intention is that each line marked with
//# 01: ..
should be flagged as an error, but the effect is that this test succeeds because a non-empty subset of the marked lines actually contains an error. The following would work:We would then notice that there is no error for
x = x + 1
, as we should.We have about 2558 occurrences of
continued
in test files undertests
; it is not obvious whether this is a single exception or the issue may affect several tests.The text was updated successfully, but these errors were encountered: