Resolve type arguments to generic methods.

Resolve type arguments to generic methods.

R=eernst@google.com

Committed: https://github.com/dart-lang/sdk/commit/33303ffea5e0ad6b6fe5fdec2a71a2ca5e2f7b91

[Johnni Winther, 2016-11-30 09:16:36]

johnniwinther@google.com changed reviewers:
+ eernst@google.com

[eernst, 2016-11-30 10:39:01]

LGTM!

https://codereview.chromium.org/2535373003/diff/1/pkg/compiler/lib/src/parser...
File pkg/compiler/lib/src/parser/parser.dart (right):

https://codereview.chromium.org/2535373003/diff/1/pkg/compiler/lib/src/parser...
pkg/compiler/lib/src/parser/parser.dart:1360: assert(token != null);
I tend to think `assert` is a separate syntactic form rather than just another
function invocation, so I'd prefer to have the space (just like `if (..)` and
`while (..)`).

But I can see that the SDK has 9651 occurrences of `assert(` and 99 occurrences
of `assert (`, so let's stick to the function call. ;)

https://codereview.chromium.org/2535373003/diff/1/pkg/compiler/lib/src/resolu...
File pkg/compiler/lib/src/resolution/members.dart (right):

https://codereview.chromium.org/2535373003/diff/1/pkg/compiler/lib/src/resolu...
pkg/compiler/lib/src/resolution/members.dart:3010:
visit(node.typeArgumentsNode);
I basically buy the argument that we can reject "meaningless" programs and
accept "meaningful ones that violate constraints".

I suspect that developers will be confused (they are not likely to see that
distinction spontaneously, and `dart2js` won't help them, it just emits warnings
about certain method invocation type arguments being non-types and accepts
malboundedness silently).

Anyway, I think almost all developers will get their messages from the analyzer,
so we don't really have to worry about all those wrong programs, because they
won't compile them before the analyzer is happy.

So we're good. ;-)

https://codereview.chromium.org/2535373003/diff/1/pkg/compiler/lib/src/tree/u...
File pkg/compiler/lib/src/tree/unparser.dart (right):

https://codereview.chromium.org/2535373003/diff/1/pkg/compiler/lib/src/tree/u...
pkg/compiler/lib/src/tree/unparser.dart:460: visit(node.typeArgumentsNode);
Yes! If this is used to format diagnostic messages to developers etc. then it is
definitely useful that we don't just drop the type arguments---that could be
quite confusing.

[Johnni Winther, 2016-11-30 11:44:36]

Description was changed from

==========
Resolve type arguments to generic methods.
==========

to

==========
Resolve type arguments to generic methods.

R=eernst@google.com

Committed:
https://github.com/dart-lang/sdk/commit/33303ffea5e0ad6b6fe5fdec2a71a2ca5e2f7b91
==========

[Johnni Winther, 2016-11-30 11:44:38]

Committed patchset #1 (id:1) manually as
33303ffea5e0ad6b6fe5fdec2a71a2ca5e2f7b91 (presubmit successful).

[Johnni Winther, 2016-11-30 11:51:03]

https://codereview.chromium.org/2535373003/diff/1/pkg/compiler/lib/src/parser...
File pkg/compiler/lib/src/parser/parser.dart (right):

https://codereview.chromium.org/2535373003/diff/1/pkg/compiler/lib/src/parser...
pkg/compiler/lib/src/parser/parser.dart:1360: assert(token != null);
On 2016/11/30 10:39:01, eernst wrote:
> I tend to think `assert` is a separate syntactic form rather than just another
> function invocation, so I'd prefer to have the space (just like `if (..)` and
> `while (..)`).
> 
> But I can see that the SDK has 9651 occurrences of `assert(` and 99
occurrences
> of `assert (`, so let's stick to the function call. ;)

Acknowledged.

https://codereview.chromium.org/2535373003/diff/1/pkg/compiler/lib/src/resolu...
File pkg/compiler/lib/src/resolution/members.dart (right):

https://codereview.chromium.org/2535373003/diff/1/pkg/compiler/lib/src/resolu...
pkg/compiler/lib/src/resolution/members.dart:3010:
visit(node.typeArgumentsNode);
On 2016/11/30 10:39:01, eernst wrote:
> I basically buy the argument that we can reject "meaningless" programs and
> accept "meaningful ones that violate constraints".
> 
> I suspect that developers will be confused (they are not likely to see that
> distinction spontaneously, and `dart2js` won't help them, it just emits
warnings
> about certain method invocation type arguments being non-types and accepts
> malboundedness silently).
> 
> Anyway, I think almost all developers will get their messages from the
analyzer,
> so we don't really have to worry about all those wrong programs, because they
> won't compile them before the analyzer is happy.
> 
> So we're good. ;-)

Acknowledged.