Add some testing for the variable allocation code in the Parser.

Add some testing for the variable allocation code in the Parser.

This cl includes a test which documents the current incorrect behavior
when capturing loop variables.

BUG=18561
R=hausner@google.com

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

[hausner, 2014-04-30 21:39:14]

LGTM with comment.

I am concerned that the tests are very brittle because they depend on exact
formatting of output, and details like token offset in the token stream when in
fact all you want to know is whether a variable is captured or not. I don't have
a suggestion how to solve this better, though.

Also, should you make the test expect the proper result and mark it as FAIL
until the issue is fixed?

[turnidge, 2014-05-01 17:29:09]

On 2014/04/30 21:39:14, hausner wrote:
> LGTM with comment.
> 
> I am concerned that the tests are very brittle because they depend on exact
> formatting of output, and details like token offset in the token stream when
in
> fact all you want to know is whether a variable is captured or not. I don't
have
> a suggestion how to solve this better, though.
> 
> Also, should you make the test expect the proper result and mark it as FAIL
> until the issue is fixed?

We discussed this a bit offline.

I agree that the test captures more information that it strictly needs.  My
feeling is that some of this testing is (token ranges of variables) is
beneficial.  As requested, I have added comments to all of the tests to
highlight which information is important for each test.

As far as depending on the exact formatting of the output, I agree that this is
true.  If the tests end up being brittle, I can rewrite them to either use a
custom string printer (just for the test) or I can edit out fields that are
troublesome.  For now, I'd like to try it as it is and see if it is a problem.

For the final test, I'm not sure exactly what the correct output would be (which
variable offset would store the saved context, etc) so I wouldn't know what the
correct output would be.  I plan on fixing the problem in my next cl, so I hope
that leaving the test in its current form is ok for the short term.

[turnidge, 2014-05-01 17:36:29]

Committed patchset #3 manually as r35643 (presubmit successful).