Add a hidden pub command to generate core library stubs.

Add a stub_core_libraries package.

This will later be used to support configuration-specific libraries.

R=rnystrom@google.com
BUG=6943
Committed: https://code.google.com/p/dart/source/detail?r=38265

[nweiz, 2014-07-09 22:53:25]

fix analyzer warnings

[nweiz, 2014-07-14 22:44:46]

analyzer fixes

[nweiz, 2014-07-14 22:45:11]

Moved this into a package. PTAL

[Bob Nystrom, 2014-07-15 17:48:34]

This looks really nice.

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/b...
File pkg/stub_core_library/bin/stub_core_library.dart (right):

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/b...
pkg/stub_core_library/bin/stub_core_library.dart:36: 'dart:html_common':
'dart_html_common.dart',
Check with Emily/Jacob/Vijay and make sure we do actually want to include this?

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
File pkg/stub_core_library/lib/stub_core_library.dart (right):

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
pkg/stub_core_library/lib/stub_core_library.dart:18: /// variables and
constructors are preserved.
"const variables and" -> "constants and const"

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
pkg/stub_core_library/lib/stub_core_library.dart:24: var generator = new
_StubVisitor(path, importReplacements);
Either call the variable "visitor" or the class "_StubGenerator". Below too.

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
pkg/stub_core_library/lib/stub_core_library.dart:31: /// [path] is used for
resolving `part` directives.
Can you explain this a bit more?

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
pkg/stub_core_library/lib/stub_core_library.dart:168: // reason not to.
Is this only for abstract methods, or non-abstract empty ones too? If the
latter, I think this may cause a forward compatibility issue. Say dart:html has:

class Foo {
  bar() {}
}

Then I do:

class Derived extends Foo {
  bar() {
    // stuff...
    super();
  }
}

I rely on this working even with the stubbed dart:html. Later, dart:html changes
Foo:

class Foo {
  bar () { notEmpty(); }
}

Now my derived bar() will throw when I call it. It's probably safest to just
prevent the user from doing this. An empty method body is a private
implementation detail of the library.

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
pkg/stub_core_library/lib/stub_core_library.dart:254: // Ignore non-const
private variables.
Why not ignore constant privates too?

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
pkg/stub_core_library/lib/stub_core_library.dart:263: _writer.print(" = null;
");
Is the "= null" just to handle final variables? If so, document that.

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
pkg/stub_core_library/lib/stub_core_library.dart:379: /// break uses of the
class as a mixin.
I like this explanation, but referring to "preserved" is confusing since this
method isn't doing the preserving. Can you explain it in terms of the predicate
the method evaluates?

https://codereview.chromium.org/380563002/diff/140001/pkg/stub_core_library/t...
File pkg/stub_core_library/test/stub_test.dart (right):

https://codereview.chromium.org/380563002/diff/140001/pkg/stub_core_library/t...
pkg/stub_core_library/test/stub_test.dart:152: Foo(int i, int j, int k, {int
l});
Nit, but can you use something other than "l" here? Maybe just make "k" the
named one?

https://codereview.chromium.org/380563002/diff/140001/pkg/stub_core_library/t...
pkg/stub_core_library/test/stub_test.dart:172: test("a constructor's field
parameters are replaced with normal "
"field parameters" -> "initializing formals".

https://codereview.chromium.org/380563002/diff/140001/pkg/stub_core_library/t...
pkg/stub_core_library/test/stub_test.dart:178: final List<int> _k;
Make one of these untyped with "var" and make sure that's handled right.

https://codereview.chromium.org/380563002/diff/140001/pkg/stub_core_library/t...
pkg/stub_core_library/test/stub_test.dart:193: test("a const constructor's
superclass calls are fully preserved", () {
Can you have a redirecting const constructor? If so, test.

[nweiz, 2014-07-15 20:09:07]

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/b...
File pkg/stub_core_library/bin/stub_core_library.dart (right):

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/b...
pkg/stub_core_library/bin/stub_core_library.dart:36: 'dart:html_common':
'dart_html_common.dart',
On 2014/07/15 17:48:33, Bob Nystrom wrote:
> Check with Emily/Jacob/Vijay and make sure we do actually want to include
this?

dart_html.dart imports it, so we need to stub it out to make that import work.

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
File pkg/stub_core_library/lib/stub_core_library.dart (right):

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
pkg/stub_core_library/lib/stub_core_library.dart:18: /// variables and
constructors are preserved.
On 2014/07/15 17:48:33, Bob Nystrom wrote:
> "const variables and" -> "constants and const"

Done.

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
pkg/stub_core_library/lib/stub_core_library.dart:24: var generator = new
_StubVisitor(path, importReplacements);
On 2014/07/15 17:48:33, Bob Nystrom wrote:
> Either call the variable "visitor" or the class "_StubGenerator". Below too.

Done.

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
pkg/stub_core_library/lib/stub_core_library.dart:31: /// [path] is used for
resolving `part` directives.
On 2014/07/15 17:48:33, Bob Nystrom wrote:
> Can you explain this a bit more?

Done.

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
pkg/stub_core_library/lib/stub_core_library.dart:168: // reason not to.
On 2014/07/15 17:48:33, Bob Nystrom wrote:
> Is this only for abstract methods, or non-abstract empty ones too? If the
> latter, I think this may cause a forward compatibility issue. Say dart:html
has:
> 
> class Foo {
>   bar() {}
> }
> 
> Then I do:
> 
> class Derived extends Foo {
>   bar() {
>     // stuff...
>     super();
>   }
> }
> 
> I rely on this working even with the stubbed dart:html. Later, dart:html
changes
> Foo:
> 
> class Foo {
>   bar () { notEmpty(); }
> }
> 
> Now my derived bar() will throw when I call it. It's probably safest to just
> prevent the user from doing this. An empty method body is a private
> implementation detail of the library.

I'm using "empty" here as per the analyzer's terminology, not in the colloquial
sense. It doesn't refer to "foo() {}" but "foo();". I'll clarify this in the
comment.

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
pkg/stub_core_library/lib/stub_core_library.dart:254: // Ignore non-const
private variables.
On 2014/07/15 17:48:33, Bob Nystrom wrote:
> Why not ignore constant privates too?

Because they might be referred to be public constants.

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
pkg/stub_core_library/lib/stub_core_library.dart:263: _writer.print(" = null;
");
On 2014/07/15 17:48:33, Bob Nystrom wrote:
> Is the "= null" just to handle final variables? If so, document that.

Done.

https://codereview.chromium.org/380563002/diff/120001/pkg/stub_core_library/l...
pkg/stub_core_library/lib/stub_core_library.dart:379: /// break uses of the
class as a mixin.
On 2014/07/15 17:48:33, Bob Nystrom wrote:
> I like this explanation, but referring to "preserved" is confusing since this
> method isn't doing the preserving. Can you explain it in terms of the
predicate
> the method evaluates?

Done.

https://codereview.chromium.org/380563002/diff/140001/pkg/stub_core_library/t...
File pkg/stub_core_library/test/stub_test.dart (right):

https://codereview.chromium.org/380563002/diff/140001/pkg/stub_core_library/t...
pkg/stub_core_library/test/stub_test.dart:152: Foo(int i, int j, int k, {int
l});
On 2014/07/15 17:48:34, Bob Nystrom wrote:
> Nit, but can you use something other than "l" here? Maybe just make "k" the
> named one?

Done.

https://codereview.chromium.org/380563002/diff/140001/pkg/stub_core_library/t...
pkg/stub_core_library/test/stub_test.dart:172: test("a constructor's field
parameters are replaced with normal "
On 2014/07/15 17:48:34, Bob Nystrom wrote:
> "field parameters" -> "initializing formals".

Done.

https://codereview.chromium.org/380563002/diff/140001/pkg/stub_core_library/t...
pkg/stub_core_library/test/stub_test.dart:178: final List<int> _k;
On 2014/07/15 17:48:34, Bob Nystrom wrote:
> Make one of these untyped with "var" and make sure that's handled right.

Done.

https://codereview.chromium.org/380563002/diff/140001/pkg/stub_core_library/t...
pkg/stub_core_library/test/stub_test.dart:193: test("a const constructor's
superclass calls are fully preserved", () {
On 2014/07/15 17:48:34, Bob Nystrom wrote:
> Can you have a redirecting const constructor? If so, test.

Done.

[Bob Nystrom, 2014-07-15 22:54:39]

LGTM!

[nweiz, 2014-07-15 23:06:12]

Committed patchset #9 manually as r38265 (presubmit successful).