Move validation to validate.dart and add comments.

tests/language/critical_edge_test.dart

Index: tests/language/critical_edge_test.dart
diff --git a/tests/language/critical_edge_test.dart b/tests/language/critical_edge_test.dart
index 4146790ef81b923cd8518f2729823fce17ff0955..28c7fd4881239aa283a4a7e0967a95c7f09b92cf 100644
--- a/tests/language/critical_edge_test.dart
+++ b/tests/language/critical_edge_test.dart
@@ -4,6 +4,31 @@
 
 // This test broke dart2js.
 // A compiler must not construct a critical edge on this program.
+//
+// In particular we have to watch out for:
+//  - the while-loop branch going to the body-block and to the exit-block, and
+//  - the exit-block having as incoming the condition-block and the
+//    break-blocks.
+//
+// Triggering the bug is relatively hard, since pushing instructions back the
+// exit-block to the incoming blocks is not guaranteed to trigger an error.
+// Dart2js frequently ended up with update-assignments just before the
+// condition:
+//    for (int i = 0; state = state0, i < 10; i++) {
+//      if (..) { state = 1; }
+//      ...
+//    }
+//    use(state);
+//
+// In this case the "state" variable was assigned before the loop and then
+// reassigned before the break. The exit-block pushed the assignment back
+// to its incoming blocks and that's why the "state = state0" assignment ended
+// up just before the condition.
+// Note that the assignment was executed at every iteration instead of just
+// when exiting the loop.
+// This repeated assignments don't have any negative effect unless the state
+// variable is also assigned and used inside the loop-body. It turns out that
+// this is very rare and needs some tricks to make happen.
 
 import "package:expect/expect.dart";