Fix error reporting when calling static methods and closures withh mismatched arguments.

Fix error reporting when calling static methods and closures withh mismatched arguments.


Closures BEFORE:
----
Unhandled exception:
Class '(dynamic, dynamic, dynamic) => dynamic' has no instance method 'call'.

NoSuchMethodError : method not found: 'call'
Receiver: Closure: (dynamic, dynamic, dynamic, dynamic) => dynamic from Function 'foo':.
Arguments: [2]

Closures NOW:
----
Closure call with mismatched arguments: function 'A.foo'

NoSuchMethodError: incorrect number of arguments passed to method named 'A.foo'
Receiver: Closure: (dynamic, dynamic, dynamic, dynamic) => dynamic from Function 'foo':.
Tried calling: A.foo(2)
Found: A.foo(a, b, c)


Statics BEFORE:
----
Unhandled exception:
No top-level method 'foo' declared.

NoSuchMethodError : method not found: 'foo'
Receiver: Type: class '::'
Arguments: []

Statics NOW:
----
Unhandled exception:
No top-level method 'foo' with matching arguments declared.

NoSuchMethodError: incorrect number of arguments passed to method named 'foo'
Receiver: top-level
Tried calling: foo(...)
Found: foo(a, b, c)

R=regis@google.com

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

[regis, 2013-04-30 19:07:10]

LGTM

https://codereview.chromium.org/14652008/diff/7007/runtime/lib/errors_patch.dart
File runtime/lib/errors_patch.dart (right):

https://codereview.chromium.org/14652008/diff/7007/runtime/lib/errors_patch.d...
runtime/lib/errors_patch.dart:26: // Differ between no arguments specified and 0
arguments.
When is _throwNew called with unspecified arguments?
I suppose that it is when we cannot resolve the method and do not bother
evaluating the arguments?
I think that the spec has changed in this regard, but not the implementation yet
(to be verified).
This case should never happen after we fix the implementation. Maybe a TODO
would be useful here.

https://codereview.chromium.org/14652008/diff/7007/runtime/lib/errors_patch.d...
runtime/lib/errors_patch.dart:114: // Actual arguments unknown.
ditto

https://codereview.chromium.org/14652008/diff/7007/runtime/lib/errors_patch.d...
runtime/lib/errors_patch.dart:115: actual_buf.write("...");
Same question.

https://codereview.chromium.org/14652008/diff/7007/runtime/vm/code_generator.cc
File runtime/vm/code_generator.cc (right):

https://codereview.chromium.org/14652008/diff/7007/runtime/vm/code_generator....
runtime/vm/code_generator.cc:1092: // name of the closurized function so that
exception contains more
There is not always a closurized function involved. What happens for a regular
closure?

[srdjan, 2013-04-30 21:46:51]

Also fixed disabled tests in object_test

https://codereview.chromium.org/14652008/diff/7007/runtime/lib/errors_patch.dart
File runtime/lib/errors_patch.dart (right):

https://codereview.chromium.org/14652008/diff/7007/runtime/lib/errors_patch.d...
runtime/lib/errors_patch.dart:26: // Differ between no arguments specified and 0
arguments.
On 2013/04/30 19:07:10, regis wrote:
> When is _throwNew called with unspecified arguments?
> I suppose that it is when we cannot resolve the method and do not bother
> evaluating the arguments?
> I think that the spec has changed in this regard, but not the implementation
yet
> (to be verified).
> This case should never happen after we fix the implementation. Maybe a TODO
> would be useful here.

Adding comments: TODO(srdjan): This can currently occur for unresolvable static
methods. In that case, the arguments are evaluated but not passed to the
throwing stub (see EffectGraphVisitor::BuildThrowNoSuchMethodError and
Parser::ThrowNoSuchMethodError).

https://codereview.chromium.org/14652008/diff/7007/runtime/lib/errors_patch.d...
runtime/lib/errors_patch.dart:114: // Actual arguments unknown.
On 2013/04/30 19:07:10, regis wrote:
> ditto

Adding TODO(regis): Remove once arguments are passed for unresolvable static
methods.

https://codereview.chromium.org/14652008/diff/7007/runtime/lib/errors_patch.d...
runtime/lib/errors_patch.dart:115: actual_buf.write("...");
On 2013/04/30 19:07:10, regis wrote:
> Same question.

Answered above.

https://codereview.chromium.org/14652008/diff/7007/runtime/vm/code_generator.cc
File runtime/vm/code_generator.cc (right):

https://codereview.chromium.org/14652008/diff/7007/runtime/vm/code_generator....
runtime/vm/code_generator.cc:1092: // name of the closurized function so that
exception contains more
On 2013/04/30 19:07:10, regis wrote:
> There is not always a closurized function involved. What happens for a regular
> closure?

It seems we always closurize, and there is always a function attached to it.

https://codereview.chromium.org/14652008/diff/7007/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://codereview.chromium.org/14652008/diff/7007/runtime/vm/object.cc#newco...
runtime/vm/object.cc:4474: }
Removed this because it hides closures from nested functions.

[srdjan, 2013-04-30 22:05:21]

Committed patchset #10 manually as r22209 (presubmit successful).