Update partial parser and scanner to be able to skip expressions like "new Map<S, T>()".

Update partial parser and scanner to be able to skip expressions like "new Map<S, T>()".

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

[Johnni Winther, 2012-06-15 11:30:51]

lgtm

[Lasse Reichstein Nielsen, 2012-06-15 11:51:13]

LGTM, I think. Not entirely sure how the stack works :)

https://chromiumcodereview.appspot.com/10544173/diff/1/dart/lib/compiler/impl...
File dart/lib/compiler/implementation/scanner/array_based_scanner.dart (right):

https://chromiumcodereview.appspot.com/10544173/diff/1/dart/lib/compiler/impl...
dart/lib/compiler/implementation/scanner/array_based_scanner.dart:52: final
syntax = keyword.syntax;
Please write the type of the variable. In this case it seems to be String, but
that isn't visible from anything except how it's used.
Omitting it does not increase readability, no matter what the style guide might
claim.

https://chromiumcodereview.appspot.com/10544173/diff/1/dart/lib/compiler/impl...
File dart/lib/compiler/implementation/scanner/partial_parser.dart (right):

https://chromiumcodereview.appspot.com/10544173/diff/1/dart/lib/compiler/impl...
dart/lib/compiler/implementation/scanner/partial_parser.dart:57: if
(!mayParseFunctionExpressions && value === '{')
While you are here, please put curly braces around this return.

[ahe, 2012-06-15 13:12:34]

Thank you, Johnni and Lasse.

I have uploaded a new version that address your comments and some documentation
of what discardOpenLt is used for. I plan to submit these changes now, but
please do take another look.

Cheers,
Peter

https://chromiumcodereview.appspot.com/10544173/diff/1/dart/lib/compiler/impl...
File dart/lib/compiler/implementation/scanner/array_based_scanner.dart (right):

https://chromiumcodereview.appspot.com/10544173/diff/1/dart/lib/compiler/impl...
dart/lib/compiler/implementation/scanner/array_based_scanner.dart:52: final
syntax = keyword.syntax;
On 2012/06/15 11:51:13, Lasse Reichstein Nielsen wrote:
> Please write the type of the variable. In this case it seems to be String, but
> that isn't visible from anything except how it's used.
> Omitting it does not increase readability, no matter what the style guide
might
> claim.

Good point.

Please be aware that when I'm writing code, you can pick one of these options
for a local variable: "final", "var", or a type. The combination of "final" and
type is not supported by me ;-)

https://chromiumcodereview.appspot.com/10544173/diff/1/dart/lib/compiler/impl...
File dart/lib/compiler/implementation/scanner/partial_parser.dart (right):

https://chromiumcodereview.appspot.com/10544173/diff/1/dart/lib/compiler/impl...
dart/lib/compiler/implementation/scanner/partial_parser.dart:57: if
(!mayParseFunctionExpressions && value === '{')
On 2012/06/15 11:51:13, Lasse Reichstein Nielsen wrote:
> While you are here, please put curly braces around this return.

No need. It fits on the previous line.

[Lasse Reichstein Nielsen, 2012-06-15 13:59:14]

Still GTLM

https://chromiumcodereview.appspot.com/10544173/diff/1/dart/lib/compiler/impl...
File dart/lib/compiler/implementation/scanner/partial_parser.dart (right):

https://chromiumcodereview.appspot.com/10544173/diff/1/dart/lib/compiler/impl...
dart/lib/compiler/implementation/scanner/partial_parser.dart:57: if
(!mayParseFunctionExpressions && value === '{')
I generally prefer to put return statements on a line by themselves, instead of
hiding them at the end of a line (except for when I don't, ofcourse).
It's because I see "return" (and "throw") as control flow operations, and I
prefer to have only one control-flow operation per line.

https://chromiumcodereview.appspot.com/10544173/diff/8001/dart/lib/compiler/i...
File dart/lib/compiler/implementation/scanner/scanner.dart (right):

https://chromiumcodereview.appspot.com/10544173/diff/8001/dart/lib/compiler/i...
dart/lib/compiler/implementation/scanner/scanner.dart:42: */
So you call this when you recognize something that can't possibly be part of a
type parameter/type argument?

https://chromiumcodereview.appspot.com/10544173/diff/8001/dart/lib/compiler/i...
dart/lib/compiler/implementation/scanner/scanner.dart:369: // > >= >> >>= >>>
>>>=
When type names can be expressions (reified types), will we be able to correctly
parse
  Set<int>==T
? And what will be correct?!? Tokenization? is! fun, :)

[ahe, 2012-06-19 11:02:41]

Thank you for your comments.

I'll follow up with a CL (that also includes the test I forgot to add).

Cheers,
Peter

https://chromiumcodereview.appspot.com/10544173/diff/1/dart/lib/compiler/impl...
File dart/lib/compiler/implementation/scanner/partial_parser.dart (right):

https://chromiumcodereview.appspot.com/10544173/diff/1/dart/lib/compiler/impl...
dart/lib/compiler/implementation/scanner/partial_parser.dart:57: if
(!mayParseFunctionExpressions && value === '{')
On 2012/06/15 13:59:14, Lasse Reichstein Nielsen wrote:
> I generally prefer to put return statements on a line by themselves, instead
of
> hiding them at the end of a line (except for when I don't, ofcourse).
> It's because I see "return" (and "throw") as control flow operations, and I
> prefer to have only one control-flow operation per line.

OK. We have used the "bailout" return can go on the same line in other places.

https://chromiumcodereview.appspot.com/10544173/diff/8001/dart/lib/compiler/i...
File dart/lib/compiler/implementation/scanner/scanner.dart (right):

https://chromiumcodereview.appspot.com/10544173/diff/8001/dart/lib/compiler/i...
dart/lib/compiler/implementation/scanner/scanner.dart:42: */
On 2012/06/15 13:59:14, Lasse Reichstein Nielsen wrote:
> So you call this when you recognize something that can't possibly be part of a
> type parameter/type argument?

Done.

https://chromiumcodereview.appspot.com/10544173/diff/8001/dart/lib/compiler/i...
dart/lib/compiler/implementation/scanner/scanner.dart:369: // > >= >> >>= >>>
>>>=
On 2012/06/15 13:59:14, Lasse Reichstein Nielsen wrote:
> When type names can be expressions (reified types), will we be able to
correctly
> parse
>   Set<int>==T
> ? And what will be correct?!? Tokenization? is! fun, :)

Yay! More fun to be had in the future. :-)