Build sdk.json without source-mirrors

Build sdk.json without source-mirrors.

This basically removes the dependency on source-mirrors from the try site and will let us delete source-mirrors from the compiler.

I was a torn for a bit about how to replace the logic here. I considered these 4
options:

(a) directly use the compiler internal APIs to crawl for reachable libraries.
(b) use `analyze-all`, then iterate over the resolved libraries.
(c) avoid parsing altogether, just enumerate recursively all files under
    sdk/lib/ and create the json file that way.
(d) submit a fixed version of the sdk, since we unlikely need it up-to-date
    for the site/try tests

I decided decided to go with (c) in this CL. It's simple and, given that the
only purpose is to preserve the site/try tests until we replace them, it seems
like the option that will slow us down the least (it makes the .json file
bigger, but that's OK now that this is not a service in use). It seemed
unnecessary to do full resolution, so I wasn't convinced of doing (b), but I did experiment with (a) now that we are
making the frontend libraries easier to use on their own. The result was OK (see
https://codereview.chromium.org/2003233002/), but probably not worth submitting
because we'd have to remember to update the code every time we modify the
internal dart2js APIs. I rather have the code in that CL be a test instead.

R=het@google.com

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

[Siggi Cherem (dart-lang), 2016-05-24 02:08:12]

Description was changed from

==========
Remove dependency from source-mirrors to create the try site.


I was a torn for a bit about how to replace the logic here. I considered these 4
options:

(a) directly use the compiler internal APIs to crawl for reachable libraries.
(b) use `analyze-all`, then iterate over the resolved libraries.
(c) avoid parsing altogether, just enumerate recursively all files under
    sdk/lib/ and create the json file that way.
(d) submit a fixed version of the sdk, since we unlikely needed it up-to-date
    for the site/try tests

I decided decided to go with (c) in this CL. It's simple and, given that the
only purpose is to preserve the site/try tests until we replace them, it seems
like the option that will slow us down the least (it makes the .json file
bigger, but that's OK now that this is not a service in use). It seemed
unnecessary to do analyze-all, and I did experiment with (a) now that we are
making the frontend libraries easier to use on their own. The result was OK (see
https://codereview.chromium.org/2003233002/), but probably not worth submitting
because we'd have to remember to update the code every time we modify the
internal dart2js APIs. I rather have the code in that CL be a test instead.
==========

to

==========
Remove dependency from source-mirrors to create the try site.


I was a torn for a bit about how to replace the logic here. I considered these 4
options:

(a) directly use the compiler internal APIs to crawl for reachable libraries.
(b) use `analyze-all`, then iterate over the resolved libraries.
(c) avoid parsing altogether, just enumerate recursively all files under
    sdk/lib/ and create the json file that way.
(d) submit a fixed version of the sdk, since we unlikely need it up-to-date
    for the site/try tests

I decided decided to go with (c) in this CL. It's simple and, given that the
only purpose is to preserve the site/try tests until we replace them, it seems
like the option that will slow us down the least (it makes the .json file
bigger, but that's OK now that this is not a service in use). It seemed
unnecessary to do full resolution, so I wasn't convinced of doing (b), but I did
experiment with (a) now that we are
making the frontend libraries easier to use on their own. The result was OK (see
https://codereview.chromium.org/2003233002/), but probably not worth submitting
because we'd have to remember to update the code every time we modify the
internal dart2js APIs. I rather have the code in that CL be a test instead.
==========

[Siggi Cherem (dart-lang), 2016-05-24 02:10:57]

Description was changed from

==========
Remove dependency from source-mirrors to create the try site.


I was a torn for a bit about how to replace the logic here. I considered these 4
options:

(a) directly use the compiler internal APIs to crawl for reachable libraries.
(b) use `analyze-all`, then iterate over the resolved libraries.
(c) avoid parsing altogether, just enumerate recursively all files under
    sdk/lib/ and create the json file that way.
(d) submit a fixed version of the sdk, since we unlikely need it up-to-date
    for the site/try tests

I decided decided to go with (c) in this CL. It's simple and, given that the
only purpose is to preserve the site/try tests until we replace them, it seems
like the option that will slow us down the least (it makes the .json file
bigger, but that's OK now that this is not a service in use). It seemed
unnecessary to do full resolution, so I wasn't convinced of doing (b), but I did
experiment with (a) now that we are
making the frontend libraries easier to use on their own. The result was OK (see
https://codereview.chromium.org/2003233002/), but probably not worth submitting
because we'd have to remember to update the code every time we modify the
internal dart2js APIs. I rather have the code in that CL be a test instead.
==========

to

==========
Build sdk.json without source-mirrors.

This basically removes the dependency on source-mirrors from the try site and
will let us delete source-mirrors from the compiler.

I was a torn for a bit about how to replace the logic here. I considered these 4
options:

(a) directly use the compiler internal APIs to crawl for reachable libraries.
(b) use `analyze-all`, then iterate over the resolved libraries.
(c) avoid parsing altogether, just enumerate recursively all files under
    sdk/lib/ and create the json file that way.
(d) submit a fixed version of the sdk, since we unlikely need it up-to-date
    for the site/try tests

I decided decided to go with (c) in this CL. It's simple and, given that the
only purpose is to preserve the site/try tests until we replace them, it seems
like the option that will slow us down the least (it makes the .json file
bigger, but that's OK now that this is not a service in use). It seemed
unnecessary to do full resolution, so I wasn't convinced of doing (b), but I did
experiment with (a) now that we are
making the frontend libraries easier to use on their own. The result was OK (see
https://codereview.chromium.org/2003233002/), but probably not worth submitting
because we'd have to remember to update the code every time we modify the
internal dart2js APIs. I rather have the code in that CL be a test instead.
==========

[Siggi Cherem (dart-lang), 2016-05-24 02:12:00]

sigmund@google.com changed reviewers:
+ ahe@google.com, het@google.com

[Harry Terkelsen, 2016-05-24 16:17:30]

lgtm

https://codereview.chromium.org/2006993002/diff/1/site/try/build_sdk_json.dart
File site/try/build_sdk_json.dart (right):

https://codereview.chromium.org/2006993002/diff/1/site/try/build_sdk_json.dar...
site/try/build_sdk_json.dart:11: print('usage: jsonify.dart <out-path>');
usage: build_sdk_json.dart <out-path>

https://codereview.chromium.org/2006993002/diff/1/site/try/build_sdk_json.dar...
site/try/build_sdk_json.dart:26:
Directory.fromUri(sdkRoot.resolve('sdk/lib/')).listSync(recursive: true)) {
run dartfmt on this?

https://codereview.chromium.org/2006993002/diff/1/site/try/build_sdk_json.dar...
site/try/build_sdk_json.dart:42: String filename = relativize(sdkRoot, uri,
false);
out of scope for this CL but the boolean flag for relativize should be a named
argument, since I have no idea what it does from reading this

[Siggi Cherem (dart-lang), 2016-05-24 16:50:11]

Description was changed from

==========
Build sdk.json without source-mirrors.

This basically removes the dependency on source-mirrors from the try site and
will let us delete source-mirrors from the compiler.

I was a torn for a bit about how to replace the logic here. I considered these 4
options:

(a) directly use the compiler internal APIs to crawl for reachable libraries.
(b) use `analyze-all`, then iterate over the resolved libraries.
(c) avoid parsing altogether, just enumerate recursively all files under
    sdk/lib/ and create the json file that way.
(d) submit a fixed version of the sdk, since we unlikely need it up-to-date
    for the site/try tests

I decided decided to go with (c) in this CL. It's simple and, given that the
only purpose is to preserve the site/try tests until we replace them, it seems
like the option that will slow us down the least (it makes the .json file
bigger, but that's OK now that this is not a service in use). It seemed
unnecessary to do full resolution, so I wasn't convinced of doing (b), but I did
experiment with (a) now that we are
making the frontend libraries easier to use on their own. The result was OK (see
https://codereview.chromium.org/2003233002/), but probably not worth submitting
because we'd have to remember to update the code every time we modify the
internal dart2js APIs. I rather have the code in that CL be a test instead.
==========

to

==========
Build sdk.json without source-mirrors.

This basically removes the dependency on source-mirrors from the try site and
will let us delete source-mirrors from the compiler.

I was a torn for a bit about how to replace the logic here. I considered these 4
options:

(a) directly use the compiler internal APIs to crawl for reachable libraries.
(b) use `analyze-all`, then iterate over the resolved libraries.
(c) avoid parsing altogether, just enumerate recursively all files under
    sdk/lib/ and create the json file that way.
(d) submit a fixed version of the sdk, since we unlikely need it up-to-date
    for the site/try tests

I decided decided to go with (c) in this CL. It's simple and, given that the
only purpose is to preserve the site/try tests until we replace them, it seems
like the option that will slow us down the least (it makes the .json file
bigger, but that's OK now that this is not a service in use). It seemed
unnecessary to do full resolution, so I wasn't convinced of doing (b), but I did
experiment with (a) now that we are
making the frontend libraries easier to use on their own. The result was OK (see
https://codereview.chromium.org/2003233002/), but probably not worth submitting
because we'd have to remember to update the code every time we modify the
internal dart2js APIs. I rather have the code in that CL be a test instead.

R=het@google.com

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

[Siggi Cherem (dart-lang), 2016-05-24 16:50:13]

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

[Siggi Cherem (dart-lang), 2016-05-24 16:50:34]

https://codereview.chromium.org/2006993002/diff/1/site/try/build_sdk_json.dart
File site/try/build_sdk_json.dart (right):

https://codereview.chromium.org/2006993002/diff/1/site/try/build_sdk_json.dar...
site/try/build_sdk_json.dart:11: print('usage: jsonify.dart <out-path>');
On 2016/05/24 16:17:30, Harry Terkelsen wrote:
> usage: build_sdk_json.dart <out-path>

Done.

https://codereview.chromium.org/2006993002/diff/1/site/try/build_sdk_json.dar...
site/try/build_sdk_json.dart:26:
Directory.fromUri(sdkRoot.resolve('sdk/lib/')).listSync(recursive: true)) {
On 2016/05/24 16:17:30, Harry Terkelsen wrote:
> run dartfmt on this?

Done. Split out subexpression to make it more readable too.

https://codereview.chromium.org/2006993002/diff/1/site/try/build_sdk_json.dar...
site/try/build_sdk_json.dart:42: String filename = relativize(sdkRoot, uri,
false);
On 2016/05/24 16:17:30, Harry Terkelsen wrote:
> out of scope for this CL but the boolean flag for relativize should be a named
> argument, since I have no idea what it does from reading this

Agree - in the future we should also migrate to use package:path where it makes
sense...