Remove reference to ObjectNotClosureException in dart2js.

Remove reference to ObjectNotClosureException in dart2js.

Now with correct co19 test expectations.

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

[Lasse Reichstein Nielsen, 2012-10-23 06:58:46]

Trying again.

[kasperl, 2012-10-23 07:06:59]

[+ahe]

LGTM, but you may want to coordinate the changes to the co19 status file with
Peter.

[ahe, 2012-10-23 07:18:44]

I think it would be really helpful if we could separate concerns as we make
changes to the language and libraries.

Concretely, I suggest that we land test changes separately from compiler/VM 
changes, and library changes separately from compiler/VM changes as far as
possible.

Experience tells us that the chances are high that changes like this are
reverted. It is unfortunate to have the tests fluctuate back and forth.

[ahe, 2012-10-23 07:19:27]

https://codereview.chromium.org/11231069/diff/1/tests/co19/co19-dart2js.status
File tests/co19/co19-dart2js.status (right):

https://codereview.chromium.org/11231069/diff/1/tests/co19/co19-dart2js.statu...
tests/co19/co19-dart2js.status:145: LibTest/core/List/filter_A03_t01: Fail, OK #
co19 issue 274
This is the perfect place to add this comment. Thank you!

[Lasse Reichstein Nielsen, 2012-10-23 07:41:17]

On 2012/10/23 07:18:44, ahe wrote:
> I think it would be really helpful if we could separate concerns as we make
> changes to the language and libraries.
> 
> Concretely, I suggest that we land test changes separately from compiler/VM 
> changes, and library changes separately from compiler/VM changes as far as
> possible.

I'm not sure I understand what this would entail.
Should we change tests first, and mark everything as failing, and then commit a
CL that implements the change and removes the fail-markings again? (Would be
good test-first-development, though.)

Most changes to libraries don't change compilers, but the ones that do will
likely make the compiler crash on everything if it isn't changed.
They are hard to separate. I agree that if there is no need for a VM/compiler
change with a library change, they should probably be separated.

> 
> Experience tells us that the chances are high that changes like this are
> reverted. It is unfortunate to have the tests fluctuate back and forth.

[ahe, 2012-10-23 08:48:23]

On 2012/10/23 07:41:17, Lasse Reichstein Nielsen wrote:
> I'm not sure I understand what this would entail.
> Should we change tests first, and mark everything as failing, and then commit
a
> CL that implements the change and removes the fail-markings again? (Would be
> good test-first-development, though.)

That is what I think would be best: change the tests first.

> Most changes to libraries don't change compilers, but the ones that do will
> likely make the compiler crash on everything if it isn't changed.
> They are hard to separate. I agree that if there is no need for a VM/compiler
> change with a library change, they should probably be separated.

That depends on how you engineer it.