First steps toward generating fully linked summaries from ASTs.

First steps toward generating fully linked summaries from ASTs.

This CL adds a summary "linker", which wil be capable of taking the
output of the prelinker and adding the information that potentially
requires traversing transitive dependencies (propagated and inferred
types, and constant constructor cycles).  When this is finished we
should be able to generate summaries straight from ASTs without
building a full element model in the interim.

The basic technique is to build a miniature element model, on demand,
which is discarded when linking is finished.  Since the miniature
element model is only for a single purpose, it can be much more
compact than the full element model.  Since it is thrown away after
linking, it can avoid the expensive dependency tracking that would be
necessary in order to keep the data structure up to date when there
are code changes.

So far I've built the basic infrastructure and started implementing
constant constructor cycle detection.  Areas that still need to be
filled out are indicated by TODO comments.

Since the linker only has access to the UnlinkedUnit objects (not the
ASTs), it will be necessary to add a small amount of information to to
the UnlinkedUnits to record the information needed by type inference.
I'm hoping that it will be possible to adapt the existing
UnlinkedConst data structure for this purpose.

R=scheglov@google.com

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

[Paul Berry, 2016-03-25 17:50:34]

paulberry@google.com changed reviewers:
+ brianwilkerson@google.com, jmesserly@google.com, scheglov@google.com

[scheglov, 2016-03-25 18:30:27]

LGTM

https://codereview.chromium.org/1828543009/diff/1/pkg/analyzer/lib/src/summar...
File pkg/analyzer/lib/src/summary/link.dart (right):

https://codereview.chromium.org/1828543009/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/link.dart:115: * Type of the callback used by
[link[ and [relin] to request
mistypes

https://codereview.chromium.org/1828543009/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/link.dart:170:
ClassElementForLink_Class(this._unlinkedClass, this.enclosingElement);
Maybe worth to keep the order of constructor parameters consistent (see
CompilationUnitElementForLink) - enclosingElement, then unlinked info.

https://codereview.chromium.org/1828543009/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/link.dart:263:
ClassElementForLink_Enum(this._unlinkedEnum);
Do we need enclosingElement too?

https://codereview.chromium.org/1828543009/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/link.dart:326: _types = <ClassElementForLink>[];
Do we want to create a fixed length list here too?

[Paul Berry, 2016-03-28 16:02:10]

https://codereview.chromium.org/1828543009/diff/1/pkg/analyzer/lib/src/summar...
File pkg/analyzer/lib/src/summary/link.dart (right):

https://codereview.chromium.org/1828543009/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/link.dart:115: * Type of the callback used by
[link[ and [relin] to request
On 2016/03/25 18:30:27, scheglov wrote:
> mistypes

Done.

https://codereview.chromium.org/1828543009/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/link.dart:170:
ClassElementForLink_Class(this._unlinkedClass, this.enclosingElement);
On 2016/03/25 18:30:27, scheglov wrote:
> Maybe worth to keep the order of constructor parameters consistent (see
> CompilationUnitElementForLink) - enclosingElement, then unlinked info.

Done.

https://codereview.chromium.org/1828543009/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/link.dart:263:
ClassElementForLink_Enum(this._unlinkedEnum);
On 2016/03/25 18:30:27, scheglov wrote:
> Do we need enclosingElement too?

I'm not sure.  I'm working on a follow up CL, and I will add it if it proves
necessary.

https://codereview.chromium.org/1828543009/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/link.dart:326: _types = <ClassElementForLink>[];
On 2016/03/25 18:30:27, scheglov wrote:
> Do we want to create a fixed length list here too?

I'm not sure it's worth it--it's a fair amount of extra bookkeeping effort since
we are populating the list from two other lists.  Let's wait and see if it shows
up significantly in profiling results.

[Paul Berry, 2016-03-28 16:02:24]

Description was changed from

==========
First steps toward generating fully linked summaries from ASTs.

This CL adds a summary "linker", which wil be capable of taking the
output of the prelinker and adding the information that potentially
requires traversing transitive dependencies (propagated and inferred
types, and constant constructor cycles).  When this is finished we
should be able to generate summaries straight from ASTs without
building a full element model in the interim.

The basic technique is to build a miniature element model, on demand,
which is discarded when linking is finished.  Since the miniature
element model is only for a single purpose, it can be much more
compact than the full element model.  Since it is thrown away after
linking, it can avoid the expensive dependency tracking that would be
necessary in order to keep the data structure up to date when there
are code changes.

So far I've built the basic infrastructure and started implementing
constant constructor cycle detection.  Areas that still need to be
filled out are indicated by TODO comments.

Since the linker only has access to the UnlinkedUnit objects (not the
ASTs), it will be necessary to add a small amount of information to to
the UnlinkedUnits to record the information needed by type inference.
I'm hoping that it will be possible to adapt the existing
UnlinkedConst data structure for this purpose.
==========

to

==========
First steps toward generating fully linked summaries from ASTs.

This CL adds a summary "linker", which wil be capable of taking the
output of the prelinker and adding the information that potentially
requires traversing transitive dependencies (propagated and inferred
types, and constant constructor cycles).  When this is finished we
should be able to generate summaries straight from ASTs without
building a full element model in the interim.

The basic technique is to build a miniature element model, on demand,
which is discarded when linking is finished.  Since the miniature
element model is only for a single purpose, it can be much more
compact than the full element model.  Since it is thrown away after
linking, it can avoid the expensive dependency tracking that would be
necessary in order to keep the data structure up to date when there
are code changes.

So far I've built the basic infrastructure and started implementing
constant constructor cycle detection.  Areas that still need to be
filled out are indicated by TODO comments.

Since the linker only has access to the UnlinkedUnit objects (not the
ASTs), it will be necessary to add a small amount of information to to
the UnlinkedUnits to record the information needed by type inference.
I'm hoping that it will be possible to adapt the existing
UnlinkedConst data structure for this purpose.

R=scheglov@google.com

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

[Paul Berry, 2016-03-28 16:02:26]

Committed patchset #1 (id:1) manually as
6455b3e5911c7c5b13afe1585a4055948e6bca2d (presubmit successful).