Issue #6429 has been merged into this issue.

I believe the spec holds in this case.

Could you update the bug with information about what you see and what you'd expect to see? I'm guessing it's the difference between getting an InvocationMirror that's a getter rather than a method?

Added this to the M2 milestone.

Yes, exactly.
The expected behavior is to call the noSuchMethod method on c with an InvocationMirror of the method call ".bar()". This is the behavior you get if there are no parentheses around "c.bar".
What I see is that the noSuchMethod method is called with an InvocationMirror of the getter access ".bar" (and then that mirror is attempted called with no arguments, which throws a NoSuchMethodError since the invocation mirror has no "call" method).

So are you saying that the spec demands

(a.b)();

to behave differently to

var temp = a.b;
(temp)();

?
This somewhat surprising, I generally expect expressions to compose.

I agree with Stephen that this is highly surprising and it certainly may trip up Dart-to-Dart translators if they aren't super careful.

cc @larsbak.

The intent of the spec was exactly the opposite: to make clear that e.m(...) is not the same as (e.m)(...). That is, given e.m(...), we do not first evaluate e.m and then do a call() which is what happens if you have the parentheses, but rather do a regular method invocation. So we need to be clear that the text that says "if e_f is a property access expression" applies to e.m but not to (e.m). I'll find away to rephrase this so it does not cause such confusion.

Set owner to @gbracha.
Removed Area-Dart2JS label.
Added Area-Language, Accepted labels.

Ok, so this is not a dart2js error. Good, I'll adapt the test that depends on this.

Would it make sense to define a closurized method as delegating the call to the original object?
If you call (o.m)(42) it works the same as o.m(42) when m accepts one parameter.
If you give an incorrect number of parameters, we could then define that to work as well, so (o.m)(42,37) should work the same as o.m(42,37) and hit the noSuchMethod on o, not on (o.m).
Effectively we define o.m to be a closure that acts as if it had a
 noSuchMethod(im) {
  if (im.memberName == "call") return im.invokeOn(o);
  return super.noSuchMethod(im); // forwarding to Object.noSuchMethod.
 }
(except that it shouldn't actually have it, it should be the call method that accepts any arguments and forwards them to o.m).

That means that o.m(...) and (o.m)(...) would act the same in all cases, not just with correct parameters.

I don't think this is necessary.

I've revised the relevant text to make this clear.

Added Done label.