Start copying resolution/inference data from front end to analyzer ASTs.

Start copying resolution/inference data from front end to analyzer ASTs.

This CL lays the groundwork for integrating the front end with
analyzer by creating a mechanism to copy resolution and type inference
information (produced by the front end's type inference engine) into
analyzer ASTs (produced by AstBuilder).

The general technique is to parse each function twice: once with
BodyBuilder as a listener and once with AstBuilder as a listener.  The
BodyBuilder generates a kernel representation of the function, but
this isn't used; instead, type inference and resolution information is
captured using ResolutionStorer (which is a TypeInferenceListener).
Later, this information is applied to the analyzer AST generated by
AstBuilder using ResolutionApplier (which is an analyzer AST visitor).

At the moment the intermediate data exchanged between ResolutionStorer
and ResolutionApplier is simply a list of types (one for each
subexpression, in a post-order traversal of the program syntax).  For
debugging and validation purposes, this is augmented with a list of
file offsets, so that if the ResolutionStorer and ResolutionApplier
get out of sync we can diagnose the problem easily.

In later CLs, more data will need to be exchanged between
ResolutionStorer and ResolutionApplier (e.g. a list of elements to
which identifiers are resolved).

This CL doesn't tackle the problem of translating between the kernel
and analyzer representation of types; for now we simply map each type
to `dynamic`.  This is sufficient for early development, since it is
still enough to let us verify that ResolutionStorer and
ResolutionApplier stay in sync.

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

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

[Paul Berry, 2017-07-12 21:27:23]

paulberry@google.com changed reviewers:
+ ahe@google.com, scheglov@google.com

[Paul Berry, 2017-07-12 21:27:23]

I'd appreciate a review from both Peter and Konstantin.

Peter--the integration with DietListener feels a bit clumsy to me at the moment.
 I'd rather not spend too much time cleaning it up right now because I think it
will change substantially when we remove kompile functionality, and when the
other parts of analyzer integration begin to take shape (e.g. creation of the
analyzer element model based on kernel).  However, if you see areas that you
think we can easily address now feel free to point them out.

[scheglov, 2017-07-12 21:43:47]

LGTM

https://codereview.chromium.org/2981693002/diff/1/pkg/analyzer/lib/src/dart/a...
File pkg/analyzer/lib/src/dart/analysis/file_state.dart (right):

https://codereview.chromium.org/2981693002/diff/1/pkg/analyzer/lib/src/dart/a...
pkg/analyzer/lib/src/dart/analysis/file_state.dart:591: true,
This probably does not matter much, given that this code is not enabled, and
might be significantly changed before it is enabled.

The plan was that we temporary use Fasta parser to get unresolved ASTs and then
resolve it using Analyzer, as a way to deprecate Analyzer's parser. So, I think
kernels are useless here.

https://codereview.chromium.org/2981693002/diff/1/pkg/analyzer/lib/src/fasta/...
File pkg/analyzer/lib/src/fasta/resolution_applier.dart (right):

https://codereview.chromium.org/2981693002/diff/1/pkg/analyzer/lib/src/fasta/...
pkg/analyzer/lib/src/fasta/resolution_applier.dart:42: node.visitChildren(this);
I think this is the default behaviour of this method.

https://codereview.chromium.org/2981693002/diff/1/pkg/analyzer/lib/src/fasta/...
pkg/analyzer/lib/src/fasta/resolution_applier.dart:55: static bool _debug =
false;
We could also make it const, not sure if this matters, but in theory then VM
could optimize it out.

[Paul Berry, 2017-07-12 22:20:12]

https://codereview.chromium.org/2981693002/diff/1/pkg/analyzer/lib/src/dart/a...
File pkg/analyzer/lib/src/dart/analysis/file_state.dart (right):

https://codereview.chromium.org/2981693002/diff/1/pkg/analyzer/lib/src/dart/a...
pkg/analyzer/lib/src/dart/analysis/file_state.dart:591: true,
On 2017/07/12 21:43:46, scheglov wrote:
> This probably does not matter much, given that this code is not enabled, and
> might be significantly changed before it is enabled.
> 
> The plan was that we temporary use Fasta parser to get unresolved ASTs and
then
> resolve it using Analyzer, as a way to deprecate Analyzer's parser. So, I
think
> kernels are useless here.

Makes sense.  Changed to `false`.

https://codereview.chromium.org/2981693002/diff/1/pkg/analyzer/lib/src/fasta/...
File pkg/analyzer/lib/src/fasta/resolution_applier.dart (right):

https://codereview.chromium.org/2981693002/diff/1/pkg/analyzer/lib/src/fasta/...
pkg/analyzer/lib/src/fasta/resolution_applier.dart:42: node.visitChildren(this);
On 2017/07/12 21:43:46, scheglov wrote:
> I think this is the default behaviour of this method.

Good point, thank you.  Removed.

https://codereview.chromium.org/2981693002/diff/1/pkg/analyzer/lib/src/fasta/...
pkg/analyzer/lib/src/fasta/resolution_applier.dart:55: static bool _debug =
false;
On 2017/07/12 21:43:46, scheglov wrote:
> We could also make it const, not sure if this matters, but in theory then VM
> could optimize it out.

Done.

[ahe, 2017-07-13 14:51:40]

lgtm

https://codereview.chromium.org/2981693002/diff/20001/pkg/analyzer/lib/src/fa...
File pkg/analyzer/lib/src/fasta/analyzer_diet_listener.dart (right):

https://codereview.chromium.org/2981693002/diff/20001/pkg/analyzer/lib/src/fa...
pkg/analyzer/lib/src/fasta/analyzer_diet_listener.dart:159: // resolution data
or inferred types.  Run the body builder and gather this
Long line.

[Paul Berry, 2017-07-13 15:54:46]

https://codereview.chromium.org/2981693002/diff/20001/pkg/analyzer/lib/src/fa...
File pkg/analyzer/lib/src/fasta/analyzer_diet_listener.dart (right):

https://codereview.chromium.org/2981693002/diff/20001/pkg/analyzer/lib/src/fa...
pkg/analyzer/lib/src/fasta/analyzer_diet_listener.dart:159: // resolution data
or inferred types.  Run the body builder and gather this
On 2017/07/13 14:51:40, ahe wrote:
> Long line.

Done.

[Paul Berry, 2017-07-13 15:55:34]

Description was changed from

==========
Start copying resolution/inference data from front end to analyzer ASTs.

This CL lays the groundwork for integrating the front end with
analyzer by creating a mechanism to copy resolution and type inference
information (produced by the front end's type inference engine) into
analyzer ASTs (produced by AstBuilder).

The general technique is to parse each function twice: once with
BodyBuilder as a listener and once with AstBuilder as a listener.  The
BodyBuilder generates a kernel representation of the function, but
this isn't used; instead, type inference and resolution information is
captured using ResolutionStorer (which is a TypeInferenceListener).
Later, this information is applied to the analyzer AST generated by
AstBuilder using ResolutionApplier (which is an analyzer AST visitor).

At the moment the intermediate data exchanged between ResolutionStorer
and ResolutionApplier is simply a list of types (one for each
subexpression, in a post-order traversal of the program syntax).  For
debugging and validation purposes, this is augmented with a list of
file offsets, so that if the ResolutionStorer and ResolutionApplier
get out of sync we can diagnose the problem easily.

In later CLs, more data will need to be exchanged between
ResolutionStorer and ResolutionApplier (e.g. a list of elements to
which identifiers are resolved).

This CL doesn't tackle the problem of translating between the kernel
and analyzer representation of types; for now we simply map each type
to `dynamic`.  This is sufficient for early development, since it is
still enough to let us verify that ResolutionStorer and
ResolutionApplier stay in sync.
==========

to

==========
Start copying resolution/inference data from front end to analyzer ASTs.

This CL lays the groundwork for integrating the front end with
analyzer by creating a mechanism to copy resolution and type inference
information (produced by the front end's type inference engine) into
analyzer ASTs (produced by AstBuilder).

The general technique is to parse each function twice: once with
BodyBuilder as a listener and once with AstBuilder as a listener.  The
BodyBuilder generates a kernel representation of the function, but
this isn't used; instead, type inference and resolution information is
captured using ResolutionStorer (which is a TypeInferenceListener).
Later, this information is applied to the analyzer AST generated by
AstBuilder using ResolutionApplier (which is an analyzer AST visitor).

At the moment the intermediate data exchanged between ResolutionStorer
and ResolutionApplier is simply a list of types (one for each
subexpression, in a post-order traversal of the program syntax).  For
debugging and validation purposes, this is augmented with a list of
file offsets, so that if the ResolutionStorer and ResolutionApplier
get out of sync we can diagnose the problem easily.

In later CLs, more data will need to be exchanged between
ResolutionStorer and ResolutionApplier (e.g. a list of elements to
which identifiers are resolved).

This CL doesn't tackle the problem of translating between the kernel
and analyzer representation of types; for now we simply map each type
to `dynamic`.  This is sufficient for early development, since it is
still enough to let us verify that ResolutionStorer and
ResolutionApplier stay in sync.

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

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

[Paul Berry, 2017-07-13 15:55:35]

Committed patchset #2 (id:20001) manually as
b87556e00df95257f242c307fcb14abb074af3e9 (presubmit successful).