Support compilation of for loops.

Support compilation of for loops.


R=srdjan@google.com
BUG=
TEST=

Committed: https://code.google.com/p/dart/source/detail?r=5219

[srdjan, 2012-03-08 17:55:12]

LGTM

https://chromiumcodereview.appspot.com/9635014/diff/1/runtime/vm/flow_graph_b...
File runtime/vm/flow_graph_builder.cc (right):

https://chromiumcodereview.appspot.com/9635014/diff/1/runtime/vm/flow_graph_b...
runtime/vm/flow_graph_builder.cc:616: if (!is_open()) return;
Should this be an assert? Can we have initializers that are not open?

[Kevin Millikin (Google), 2012-03-09 08:52:52]

https://chromiumcodereview.appspot.com/9635014/diff/1/runtime/vm/flow_graph_b...
File runtime/vm/flow_graph_builder.cc (right):

https://chromiumcodereview.appspot.com/9635014/diff/1/runtime/vm/flow_graph_b...
runtime/vm/flow_graph_builder.cc:616: if (!is_open()) return;
On 2012/03/08 17:55:12, srdjan wrote:
> Should this be an assert? Can we have initializers that are not open?

Other than the throw in expression context issue that we have already assumed
will be changed somehow, I don't think we can have initializers that are not
open---from the concrete syntax there are no statement subparts.

On the other hand, it is a SequenceNode, and our assumption was that
SequenceNodes can have escapes, so I decided to write the code so it would not
assume otherwise.  Nothing in the types prevents abuses in the parser code like
putting a throw in there.  I actually prefer in that case to make this code
work, rather than relying on code coverage and tests to uncover a debug ASSERT.

This is a case where IMO it actively hurts us to discard the structure of the
concrete syntax in favor of an untyped AST representation.

I'll change this to an assert for now.