Support type annotations for list literals.

Support type annotations for list literals.

R=ahe@google.com,smok@google.com

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

[Roman, 2012-07-31 17:55:35]

lgtm

[ahe, 2012-07-31 18:11:09]

On 2012/07/31 17:55:35, Roman wrote:
> lgtm

Sorry, not looking good to me :-)

I'll follow up with details tomorrow. Generally, we want the parser to accept as
much as possible, so we should accept multiple type arguments and reject them in
the resolver. 

Also, I'm not sure positions are recorded correctly.

[ahe, 2012-08-23 13:06:35]

I will revert this change. It has been three weeks since I first pointed out
issues with this change, but since then nothing has happened.

Simple test cases like these:

main() {
  print(<int, int>[]);
}

main() {
  print(const <int, int>[]);
}

Cause the compiler to crash in two different ways.

As far as I can tell, this change was virtually untested when viewed as a change
to dart2js. When you make a change to dart2js to implement a new semantic check
(as you did in this CL), there should be some existing tests that start passing.
Otherwise, you have to write a test yourself.

https://chromiumcodereview.appspot.com/10849002/diff/1/lib/compiler/implement...
File lib/compiler/implementation/scanner/listener.dart (right):

https://chromiumcodereview.appspot.com/10849002/diff/1/lib/compiler/implement...
lib/compiler/implementation/scanner/listener.dart:1273: if
(typeArguments.length() != 1) {
The method [length] is O(n). The method [length] should be renamed to
slowLength. So as a general rule, you shouldn't use length. In this case it
doesn't matter as the correct answer will be fast. However, I prefer avoid using
methods like this altogether as people may use them in other situations.

https://chromiumcodereview.appspot.com/10849002/diff/1/lib/compiler/implement...
lib/compiler/implementation/scanner/listener.dart:1274: error('Type annotations
for list literal should have a single type',
If this error should be reported here, it should be using [recoverableError].
However, the error should not be reported here as this can just as well be
checked in the resolver where we normally validate types.

The method [error] throws an exception and is not supposed to be used directly.

https://chromiumcodereview.appspot.com/10849002/diff/1/lib/compiler/implement...
lib/compiler/implementation/scanner/listener.dart:1275: constKeyword.next);
This error position is wrong. First, there may be no constKeyword. Second, the
problem is either:

1. Too few type arguments (as in <>[]). However, that cannot currently happen.
But it might if we improve recovery in other parts of the parser. In this case,
the position is typeArguments.beginToken.

2. Too many type arguments (as in <int, int>[]). In this case, the position is
typeArguments.nodes.tail.head.

https://chromiumcodereview.appspot.com/10849002/diff/1/lib/compiler/implement...
lib/compiler/implementation/scanner/listener.dart:1277: type =
typeArguments.iterator().next();
Calling iterator always creates a new object. This is why we generally use the
fact that Links are linked lists. So this would be: typeArguments.nodes.head.

https://chromiumcodereview.appspot.com/10849002/diff/1/lib/compiler/implement...
lib/compiler/implementation/scanner/listener.dart:1278: }
Unfortunately, you discarded the NodeList and now you need a special case for
printing the type arguments, and a special case for finding the the source
position corresponding to the type arguments.

[Anton Muhin, 2012-08-23 13:10:03]

Up to you, Peter

[Anton Muhin, 2012-08-23 13:11:19]

On 2012/08/23 13:10:03, Anton Muhin wrote:
> Up to you, Peter

And just in case: I didn't action on this as you promised to follow up
"tomorrow" on this, but it only happend 3 mins ago.

yours,
anton.