Added a test for dump-info with lots of closures.

Added a test for dump-info with lots of closures.

BUG=
R=sra@google.com

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

[Ty Overby (Google), 2014-08-13 21:27:36]

Florian: This adds the test that you mentioned in
https://codereview.chromium.org/435263002/

[sra1, 2014-08-13 21:45:26]

https://codereview.chromium.org/469903002/diff/20001/sdk/lib/_internal/compil...
File sdk/lib/_internal/compiler/implementation/dump_info.dart (right):

https://codereview.chromium.org/469903002/diff/20001/sdk/lib/_internal/compil...
sdk/lib/_internal/compiler/implementation/dump_info.dart:196:
compiler.typesTask.getGuaranteedTypeOfElement(element);
indent by +4 when breaking an expression

https://codereview.chromium.org/469903002/diff/20001/sdk/lib/_internal/compil...
File sdk/lib/_internal/compiler/implementation/inferrer/type_graph_inferrer.dart
(right):

https://codereview.chromium.org/469903002/diff/20001/sdk/lib/_internal/compil...
sdk/lib/_internal/compiler/implementation/inferrer/type_graph_inferrer.dart:1133:
// case, so return null indicating that the type could not be inferred.
When does this happen?
When the input is has parse errors?
Perhaps the underlying condition (e.g. parse error) should block whatever task
is calling getTypeOfElement.

https://codereview.chromium.org/469903002/diff/20001/tests/compiler/dart2js/d...
File tests/compiler/dart2js/dump_info_test.dart (right):

https://codereview.chromium.org/469903002/diff/20001/tests/compiler/dart2js/d...
tests/compiler/dart2js/dump_info_test.dart:62: typedef void
JsonTaking(Map<String, dynamic> json);
I'd put a line between top level declarations unless they are all single-line
related constants.

[Ty Overby (Google), 2014-08-13 22:00:31]

https://codereview.chromium.org/469903002/diff/20001/sdk/lib/_internal/compil...
File sdk/lib/_internal/compiler/implementation/dump_info.dart (right):

https://codereview.chromium.org/469903002/diff/20001/sdk/lib/_internal/compil...
sdk/lib/_internal/compiler/implementation/dump_info.dart:196:
compiler.typesTask.getGuaranteedTypeOfElement(element);
On 2014/08/13 21:45:26, sra1 wrote:
> indent by +4 when breaking an expression

Done.

https://codereview.chromium.org/469903002/diff/20001/sdk/lib/_internal/compil...
File sdk/lib/_internal/compiler/implementation/inferrer/type_graph_inferrer.dart
(right):

https://codereview.chromium.org/469903002/diff/20001/sdk/lib/_internal/compil...
sdk/lib/_internal/compiler/implementation/inferrer/type_graph_inferrer.dart:1133:
// case, so return null indicating that the type could not be inferred.
On 2014/08/13 21:45:26, sra1 wrote:
> When does this happen?
> When the input is has parse errors?
> Perhaps the underlying condition (e.g. parse error) should block whatever task
> is calling getTypeOfElement.
> 

This happens on otherwise perfectly behaving code when DumpInfoTask tries to
look up the type of some elements.  This condition is not hit in any real-world
code that I've tried, but it did unexpectedly break when analyzing the
many-closures test case that you suggested.

https://codereview.chromium.org/469903002/diff/20001/tests/compiler/dart2js/d...
File tests/compiler/dart2js/dump_info_test.dart (right):

https://codereview.chromium.org/469903002/diff/20001/tests/compiler/dart2js/d...
tests/compiler/dart2js/dump_info_test.dart:62: typedef void
JsonTaking(Map<String, dynamic> json);
On 2014/08/13 21:45:26, sra1 wrote:
> I'd put a line between top level declarations unless they are all single-line
> related constants.

Done.

[sra1, 2014-08-13 22:16:27]

https://codereview.chromium.org/469903002/diff/20001/sdk/lib/_internal/compil...
File sdk/lib/_internal/compiler/implementation/inferrer/type_graph_inferrer.dart
(right):

https://codereview.chromium.org/469903002/diff/20001/sdk/lib/_internal/compil...
sdk/lib/_internal/compiler/implementation/inferrer/type_graph_inferrer.dart:1133:
// case, so return null indicating that the type could not be inferred.
On 2014/08/13 22:00:31, Ty Overby (Google) wrote:
> On 2014/08/13 21:45:26, sra1 wrote:
> > When does this happen?
> > When the input is has parse errors?
> > Perhaps the underlying condition (e.g. parse error) should block whatever
task
> > is calling getTypeOfElement.
> > 
> 
> This happens on otherwise perfectly behaving code when DumpInfoTask tries to
> look up the type of some elements.  This condition is not hit in any
real-world
> code that I've tried, but it did unexpectedly break when analyzing the
> many-closures test case that you suggested.

So TypeGraphInferer.analyzeMain is not called, but compiler.disableTypeInference
is false?
That seems very odd.  

Is there something different about how the compiler (the Compiler from
compilerFor in memory_compiler.dart) is running? 
I'd rather understand what is going on with that than make this change.

Florian - any ideas?

[Ty Overby (Google), 2014-08-13 22:34:48]

On 2014/08/13 22:16:27, sra1 wrote:
>
https://codereview.chromium.org/469903002/diff/20001/sdk/lib/_internal/compil...
> File
sdk/lib/_internal/compiler/implementation/inferrer/type_graph_inferrer.dart
> (right):
> 
>
https://codereview.chromium.org/469903002/diff/20001/sdk/lib/_internal/compil...
>
sdk/lib/_internal/compiler/implementation/inferrer/type_graph_inferrer.dart:1133:
> // case, so return null indicating that the type could not be inferred.
> On 2014/08/13 22:00:31, Ty Overby (Google) wrote:
> > On 2014/08/13 21:45:26, sra1 wrote:
> > > When does this happen?
> > > When the input is has parse errors?
> > > Perhaps the underlying condition (e.g. parse error) should block whatever
> task
> > > is calling getTypeOfElement.
> > > 
> > 
> > This happens on otherwise perfectly behaving code when DumpInfoTask tries to
> > look up the type of some elements.  This condition is not hit in any
> real-world
> > code that I've tried, but it did unexpectedly break when analyzing the
> > many-closures test case that you suggested.
> 
> So TypeGraphInferer.analyzeMain is not called, but
compiler.disableTypeInference
> is false?
> That seems very odd.  
> 
> Is there something different about how the compiler (the Compiler from
> compilerFor in memory_compiler.dart) is running? 
> I'd rather understand what is going on with that than make this change.
> 
> Florian - any ideas?

This issue was resolved in person.  The check that I introduced was not 
necessary and the real failure is now checked for in the test helper function.

[sra1, 2014-08-13 22:43:56]

lgtm

[Ty Overby (Google), 2014-08-13 22:56:04]

Committed patchset #4 manually as 39230 (presubmit successful).