Basic linking in PubSummaryManager.

Basic linking in PubSummaryManager.

Many features are not implemented yet, but I'd like to show to you and
if it a step in the correct directlion, land it.

R=paulberry@google.com
BUG=

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

[Paul Berry, 2016-08-09 22:24:11]

lgtm as a starting point.  I have some concerns below but feel free to land as
is and we can iterate.

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

https://codereview.chromium.org/2226973005/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/pub_summary.dart:398: // Ignore SDK imports.
I'm concerned that treating the SDK specially may be a mistake.  If the user
downloads a new release of the SDK, then assuming that SDK exposes a different
API signature than the previous version, everything will need to be re-linked. 
I think the easiest way to make sure this happens correctly is to treat the SDK
as a separate build unit, and don't try to do any special casing of the
dependency computation algorithm.  That way all the packages will automatically
depend on the SDK, so the SDK's API signature will automatically get included in
the dependency hash for those packages, and things will get re-linked as
appropiate.

A similar situations exists for Flutter, but it's more complicated, for two
reasons: 1. Flutter modifies the SDK using _embedder.yaml, so the summary we'll
need to use for the SDK is different from the standard SDK summary.  2. Flutter
extends the SDK using _sdkext, and that extension in effect constitutes a
separate build unit.  I'm not sure how to handle #1 yet, but I think the way to
handle #2 is just to let it be in its own summary, and let the
computeDependencies() algorithm treat it normally.

https://codereview.chromium.org/2226973005/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/pub_summary.dart:400: referencedUris.add(uri);
This seems unnecessarily complex.  Since there's always exactly one node per
package, can't we just extract the package name at this point and then map it to
a node?

(Or maybe you are hoping some of this code can be re-used in use cases where
there are multiple summaries per package)

https://codereview.chromium.org/2226973005/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/pub_summary.dart:425: print('evaluate: $v');
Delete

[scheglov, 2016-08-10 01:03:19]

Description was changed from

==========
Basic linking in PubSummaryManager.

Many features are not implemented yet, but I'd like to show to you and
if it a step in the correct directlion, land it.

R=paulberry@google.com
BUG=
==========

to

==========
Basic linking in PubSummaryManager.

Many features are not implemented yet, but I'd like to show to you and
if it a step in the correct directlion, land it.

R=paulberry@google.com
BUG=

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

[scheglov, 2016-08-10 01:03:21]

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

[scheglov, 2016-08-10 01:12:49]

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

https://codereview.chromium.org/2226973005/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/pub_summary.dart:398: // Ignore SDK imports.
On 2016/08/09 22:24:10, Paul Berry wrote:
> I'm concerned that treating the SDK specially may be a mistake.  If the user
> downloads a new release of the SDK, then assuming that SDK exposes a different
> API signature than the previous version, everything will need to be re-linked.

> I think the easiest way to make sure this happens correctly is to treat the
SDK
> as a separate build unit, and don't try to do any special casing of the
> dependency computation algorithm.  That way all the packages will
automatically
> depend on the SDK, so the SDK's API signature will automatically get included
in
> the dependency hash for those packages, and things will get re-linked as
> appropiate.

  Yes, at the point when we will store linked summaries into file system, we
need to use SDK and referenced packages API signatures.

> 
> A similar situations exists for Flutter, but it's more complicated, for two
> reasons: 1. Flutter modifies the SDK using _embedder.yaml, so the summary
we'll
> need to use for the SDK is different from the standard SDK summary.  2.
Flutter
> extends the SDK using _sdkext, and that extension in effect constitutes a
> separate build unit.  I'm not sure how to handle #1 yet, but I think the way
to
> handle #2 is just to let it be in its own summary, and let the
> computeDependencies() algorithm treat it normally.

https://codereview.chromium.org/2226973005/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/pub_summary.dart:400: referencedUris.add(uri);
On 2016/08/09 22:24:10, Paul Berry wrote:
> This seems unnecessarily complex.  Since there's always exactly one node per
> package, can't we just extract the package name at this point and then map it
to
> a node?
> 
> (Or maybe you are hoping some of this code can be re-used in use cases where
> there are multiple summaries per package)

True, this can be simplified.
No, I don't plan to split packages into multiple linked bundles.

https://codereview.chromium.org/2226973005/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/pub_summary.dart:425: print('evaluate: $v');
On 2016/08/09 22:24:10, Paul Berry wrote:
> Delete

Done.