Organize summary declarations by unit rather than by library.

Organize summary declarations by unit rather than by library.

In the initial implementation of summaries, all declarations for a
given library were thrown together into a single bucket, regardless of
the compilation unit in which they appeared.  This was done on the
grounds that semantically, the compilation unit in which a declaration
appears is irrelevant.

However, it turns out that this conflicts with one of the design goals
of summaries, which is to allow summaries to be quickly "re-linked"
when URI resolution changes.  Since "part" declarations use URIs to
refer to part files, this means that URI resolution may affect the
relationship among compilation units within a library; thus, the
declarations for each compilation unit need to be in their own data
structure.

A side benefit of this reorganization is to make the structure of the
summary more similar to the structure of the element model; this
should in turn make it simpler (and possibly more performant) to
convert between element models and summaries.

This CL reorganizes the declarations themselves; future CLs will
reorganize the dependency and resolution information to match.

R=brianwilkerson@google.com

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

[Paul Berry, 2015-12-14 22:56:11]

paulberry@google.com changed reviewers:
+ brianwilkerson@google.com

[Paul Berry, 2015-12-14 22:56:12]

Brian, I recall that one of your suggestions when I first started working on
summaries was that I should group declarations by compilation unit.  You were
right.

[Brian Wilkerson, 2015-12-14 23:44:35]

LGTM

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

https://codereview.chromium.org/1530503002/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/summarize_elements.dart:141: // TODO(paulberry): we
need to figure out a way to record library, part,
We might have discussed this already, but if not it might be worth asking
(off-line) whether we should do that, or whether we should only create summaries
for valid compilation units?

[Paul Berry, 2015-12-15 00:29:56]

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

https://codereview.chromium.org/1530503002/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/summarize_elements.dart:141: // TODO(paulberry): we
need to figure out a way to record library, part,
On 2015/12/14 23:44:35, Brian Wilkerson wrote:
> We might have discussed this already, but if not it might be worth asking
> (off-line) whether we should do that, or whether we should only create
summaries
> for valid compilation units?

Agreed, that would be a good discussion to have.  My instinct is that for now,
that's a totally reasonable restriction (since our initial use of summaries will
be for things like published packages and the SDK, where we can rely on the
compilation units being well-formed).  If, at some later date, we are
contemplating using summaries to speed up on-the-fly analysis of files that are
being actively edited, we may need to be more careful about the semantics of
summarizing invalid code.

(Incidentally, in our planning meeting today, I made a task for "Element model
enhancements (to support re-linking)").  It would probably be good to have this
discussion in the context of that task.

[Paul Berry, 2015-12-15 00:30:19]

Description was changed from

==========
Organize summary declarations by unit rather than by library.

In the initial implementation of summaries, all declarations for a
given library were thrown together into a single bucket, regardless of
the compilation unit in which they appeared.  This was done on the
grounds that semantically, the compilation unit in which a declaration
appears is irrelevant.

However, it turns out that this conflicts with one of the design goals
of summaries, which is to allow summaries to be quickly "re-linked"
when URI resolution changes.  Since "part" declarations use URIs to
refer to part files, this means that URI resolution may affect the
relationship among compilation units within a library; thus, the
declarations for each compilation unit need to be in their own data
structure.

A side benefit of this reorganization is to make the structure of the
summary more similar to the structure of the element model; this
should in turn make it simpler (and possibly more performant) to
convert between element models and summaries.

This CL reorganizes the declarations themselves; future CLs will
reorganize the dependency and resolution information to match.
==========

to

==========
Organize summary declarations by unit rather than by library.

In the initial implementation of summaries, all declarations for a
given library were thrown together into a single bucket, regardless of
the compilation unit in which they appeared.  This was done on the
grounds that semantically, the compilation unit in which a declaration
appears is irrelevant.

However, it turns out that this conflicts with one of the design goals
of summaries, which is to allow summaries to be quickly "re-linked"
when URI resolution changes.  Since "part" declarations use URIs to
refer to part files, this means that URI resolution may affect the
relationship among compilation units within a library; thus, the
declarations for each compilation unit need to be in their own data
structure.

A side benefit of this reorganization is to make the structure of the
summary more similar to the structure of the element model; this
should in turn make it simpler (and possibly more performant) to
convert between element models and summaries.

This CL reorganizes the declarations themselves; future CLs will
reorganize the dependency and resolution information to match.

R=brianwilkerson@google.com

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

[Paul Berry, 2015-12-15 00:30:20]

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