Type annotations instead of closure comments.

Emit TypeScript / Closure ES6_TYPED type annotations in --closure mode (instead of closure comments).

- Replaced ClosureType by a general JS.TypeRef, used in AST for identifier types, return types
- Convert DartType to JS.TypeRef (in mixin JsTypeRefCodegen), including type parameters (also added to AST in Fun & ClassExpression)
- Emit field declarations expected by TS
- Wrote a TypeScriptTypePrinter (mixed in by Printer) and a ClosureTypePrinter (might disappear soon)
- Simplified annotation code, called in more places (seems to gives more source info)

Example input:

  List/*<T>*/ func/*<T>*/(List/*<T>*/ items, dynamic/*=T*/ seed) {}

  class Foo<T> {
    int i;
    static var x;
    Foo(this.i, o, {String v : "?"}) {}
  }

Output:

  function func<T>(items: core.List<T>, seed: T): core.List<T> {}

  const Foo$ = dart.generic(function(T) {
    class Foo<T> extends core.Object {
      i: number;
      static x;
      Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
        this.i = i;
      }
    }
    ...
    Foo.x = null;
    return Foo;
  });

Known remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports, or we'll need a different temp + extra type annotations of the default-exported object).
- Generic type is currently locked inside the generic call. Might be able to solve by exporting signatures in .d.ts file, or changing the way we do generics.

BUG=
R=jmesserly@google.com

Committed: https://github.com/dart-lang/dev_compiler/commit/2b3823f4a9309c23b0b1d1c0faa31df5f9a24c54

[ochafik, 2016-02-05 17:31:28]

Description was changed from

==========
Type annotations instead of closure comments.
(accepted by both Closure (--language_in=ES6_TYPED) and TypeScript)

BUG=
==========

to

==========
Embracing TypeScript / Closure ES6_TYPED type annotations in --closure mode
(instead of closure comments).

Example input:
class Foo<T> {
  int i;
  static var x;
  Foo(this.i, o, {String v : "?"}) {}
}

Output:
const Foo$ = dart.generic(function(T) {
  class Foo<T> extends core.Object {
    i: number;
    static x;
    Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
      this.i = i;
    }
  }
  ...
  Foo.x = null;
  return Foo;
});
BUG=
==========

[ochafik, 2016-02-05 17:34:57]

Description was changed from

==========
Embracing TypeScript / Closure ES6_TYPED type annotations in --closure mode
(instead of closure comments).

Example input:
class Foo<T> {
  int i;
  static var x;
  Foo(this.i, o, {String v : "?"}) {}
}

Output:
const Foo$ = dart.generic(function(T) {
  class Foo<T> extends core.Object {
    i: number;
    static x;
    Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
      this.i = i;
    }
  }
  ...
  Foo.x = null;
  return Foo;
});
BUG=
==========

to

==========
Embracing TypeScript / Closure ES6_TYPED type annotations in --closure mode
(instead of closure comments).

Example input:
class Foo<T> {
  int i;
  static var x;
  Foo(this.i, o, {String v : "?"}) {}
}

Output:
const Foo$ = dart.generic(function(T) {
  class Foo<T> extends core.Object {
    i: number;
    static x;
    Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
      this.i = i;
    }
  }
  ...
  Foo.x = null;
  return Foo;
});

Remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports,
or we'll need a different temp + extra type annotations of the default-exported
object).
- core functions like dart.generic will need bespoke type signatures to let
types propagate

BUG=
==========

[ochafik, 2016-02-05 18:05:22]

Description was changed from

==========
Embracing TypeScript / Closure ES6_TYPED type annotations in --closure mode
(instead of closure comments).

Example input:
class Foo<T> {
  int i;
  static var x;
  Foo(this.i, o, {String v : "?"}) {}
}

Output:
const Foo$ = dart.generic(function(T) {
  class Foo<T> extends core.Object {
    i: number;
    static x;
    Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
      this.i = i;
    }
  }
  ...
  Foo.x = null;
  return Foo;
});

Remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports,
or we'll need a different temp + extra type annotations of the default-exported
object).
- core functions like dart.generic will need bespoke type signatures to let
types propagate

BUG=
==========

to

==========
Embracing TypeScript / Closure ES6_TYPED type annotations in --closure mode
(instead of closure comments).

Example input:

  List/*<T>*/ func/*<T>*/(List/*<T>*/ items, dynamic/*=T*/ seed)
  class Foo<T> {
    int i;
    static var x;
    Foo(this.i, o, {String v : "?"}) {}
  }

Output:
  function func<T>(items: core.List<T>, seed: T): core.List<T> {}
  const Foo$ = dart.generic(function(T) {
    class Foo<T> extends core.Object {
      i: number;
      static x;
      Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
        this.i = i;
      }
    }
    ...
    Foo.x = null;
    return Foo;
  });

Remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports,
or we'll need a different temp + extra type annotations of the default-exported
object).
- core functions like dart.generic will need bespoke type signatures to let
types propagate

BUG=
==========

[ochafik, 2016-02-05 18:06:05]

Description was changed from

==========
Embracing TypeScript / Closure ES6_TYPED type annotations in --closure mode
(instead of closure comments).

Example input:

  List/*<T>*/ func/*<T>*/(List/*<T>*/ items, dynamic/*=T*/ seed)
  class Foo<T> {
    int i;
    static var x;
    Foo(this.i, o, {String v : "?"}) {}
  }

Output:
  function func<T>(items: core.List<T>, seed: T): core.List<T> {}
  const Foo$ = dart.generic(function(T) {
    class Foo<T> extends core.Object {
      i: number;
      static x;
      Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
        this.i = i;
      }
    }
    ...
    Foo.x = null;
    return Foo;
  });

Remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports,
or we'll need a different temp + extra type annotations of the default-exported
object).
- core functions like dart.generic will need bespoke type signatures to let
types propagate

BUG=
==========

to

==========
Emit TypeScript / Closure ES6_TYPED type annotations in --closure mode (instead
of closure comments).

Example input:

  List/*<T>*/ func/*<T>*/(List/*<T>*/ items, dynamic/*=T*/ seed)
  class Foo<T> {
    int i;
    static var x;
    Foo(this.i, o, {String v : "?"}) {}
  }

Output:
  function func<T>(items: core.List<T>, seed: T): core.List<T> {}
  const Foo$ = dart.generic(function(T) {
    class Foo<T> extends core.Object {
      i: number;
      static x;
      Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
        this.i = i;
      }
    }
    ...
    Foo.x = null;
    return Foo;
  });

Known remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports,
or we'll need a different temp + extra type annotations of the default-exported
object).

BUG=
==========

[ochafik, 2016-02-05 18:10:52]

Description was changed from

==========
Emit TypeScript / Closure ES6_TYPED type annotations in --closure mode (instead
of closure comments).

Example input:

  List/*<T>*/ func/*<T>*/(List/*<T>*/ items, dynamic/*=T*/ seed)
  class Foo<T> {
    int i;
    static var x;
    Foo(this.i, o, {String v : "?"}) {}
  }

Output:
  function func<T>(items: core.List<T>, seed: T): core.List<T> {}
  const Foo$ = dart.generic(function(T) {
    class Foo<T> extends core.Object {
      i: number;
      static x;
      Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
        this.i = i;
      }
    }
    ...
    Foo.x = null;
    return Foo;
  });

Known remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports,
or we'll need a different temp + extra type annotations of the default-exported
object).

BUG=
==========

to

==========
Emit TypeScript / Closure ES6_TYPED type annotations in --closure mode (instead
of closure comments).

- Replaced ClosureType by a general JS.TypeRef, used in AST for identifier
types, return types,
- Convert DartType to JS.TypeRef (in mixin JsTypeRefCodegen), including type
parameters (also added to AST in Fun & ClassExpression)
- Wrote a TypeScriptTypePrinter (mixed in by Printer) and a ClosureTypePrinter
(might disappear soon)
- Simplified annotation code, called in more places (seems to gives more source
info)

Example input:

  List/*<T>*/ func/*<T>*/(List/*<T>*/ items, dynamic/*=T*/ seed)
  class Foo<T> {
    int i;
    static var x;
    Foo(this.i, o, {String v : "?"}) {}
  }

Output:
  function func<T>(items: core.List<T>, seed: T): core.List<T> {}
  const Foo$ = dart.generic(function(T) {
    class Foo<T> extends core.Object {
      i: number;
      static x;
      Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
        this.i = i;
      }
    }
    ...
    Foo.x = null;
    return Foo;
  });

Known remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports,
or we'll need a different temp + extra type annotations of the default-exported
object).

BUG=
==========

[ochafik, 2016-02-05 18:13:00]

Description was changed from

==========
Emit TypeScript / Closure ES6_TYPED type annotations in --closure mode (instead
of closure comments).

- Replaced ClosureType by a general JS.TypeRef, used in AST for identifier
types, return types,
- Convert DartType to JS.TypeRef (in mixin JsTypeRefCodegen), including type
parameters (also added to AST in Fun & ClassExpression)
- Wrote a TypeScriptTypePrinter (mixed in by Printer) and a ClosureTypePrinter
(might disappear soon)
- Simplified annotation code, called in more places (seems to gives more source
info)

Example input:

  List/*<T>*/ func/*<T>*/(List/*<T>*/ items, dynamic/*=T*/ seed)
  class Foo<T> {
    int i;
    static var x;
    Foo(this.i, o, {String v : "?"}) {}
  }

Output:
  function func<T>(items: core.List<T>, seed: T): core.List<T> {}
  const Foo$ = dart.generic(function(T) {
    class Foo<T> extends core.Object {
      i: number;
      static x;
      Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
        this.i = i;
      }
    }
    ...
    Foo.x = null;
    return Foo;
  });

Known remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports,
or we'll need a different temp + extra type annotations of the default-exported
object).

BUG=
==========

to

==========
Emit TypeScript / Closure ES6_TYPED type annotations in --closure mode (instead
of closure comments).

- Replaced ClosureType by a general JS.TypeRef, used in AST for identifier
types, return types
- Convert DartType to JS.TypeRef (in mixin JsTypeRefCodegen), including type
parameters (also added to AST in Fun & ClassExpression)
- Emit field declarations expected by TS
- Wrote a TypeScriptTypePrinter (mixed in by Printer) and a ClosureTypePrinter
(might disappear soon)
- Simplified annotation code, called in more places (seems to gives more source
info)

Example input:

  List/*<T>*/ func/*<T>*/(List/*<T>*/ items, dynamic/*=T*/ seed)
  class Foo<T> {
    int i;
    static var x;
    Foo(this.i, o, {String v : "?"}) {}
  }

Output:
  function func<T>(items: core.List<T>, seed: T): core.List<T> {}
  const Foo$ = dart.generic(function(T) {
    class Foo<T> extends core.Object {
      i: number;
      static x;
      Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
        this.i = i;
      }
    }
    ...
    Foo.x = null;
    return Foo;
  });

Known remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports,
or we'll need a different temp + extra type annotations of the default-exported
object).

BUG=
==========

[ochafik, 2016-02-05 18:13:25]

Patchset #1 (id:1) has been deleted

[ochafik, 2016-02-05 18:13:33]

Patchset #1 (id:20001) has been deleted

[ochafik, 2016-02-05 18:13:42]

Patchset #1 (id:40001) has been deleted

[ochafik, 2016-02-05 18:13:49]

Patchset #1 (id:60001) has been deleted

[ochafik, 2016-02-05 18:13:57]

Patchset #1 (id:80001) has been deleted

[ochafik, 2016-02-05 18:14:05]

Patchset #2 (id:120001) has been deleted

[ochafik, 2016-02-05 18:14:11]

Patchset #1 (id:100001) has been deleted

[ochafik, 2016-02-05 22:03:36]

ochafik@google.com changed reviewers:
+ jmesserly@google.com, leafp@google.com, vsm@google.com

[ochafik, 2016-02-05 22:03:37]

Hi guys, here's a timid attempt to bring TypeScript annotations to our AST.

The output matches what (latest) TypeScript & Closure (with
--language_in=ES6_TYPED) expect, with some limitations (listed in the cl's
description).

[ochafik, 2016-02-08 15:35:51]

Description was changed from

==========
Emit TypeScript / Closure ES6_TYPED type annotations in --closure mode (instead
of closure comments).

- Replaced ClosureType by a general JS.TypeRef, used in AST for identifier
types, return types
- Convert DartType to JS.TypeRef (in mixin JsTypeRefCodegen), including type
parameters (also added to AST in Fun & ClassExpression)
- Emit field declarations expected by TS
- Wrote a TypeScriptTypePrinter (mixed in by Printer) and a ClosureTypePrinter
(might disappear soon)
- Simplified annotation code, called in more places (seems to gives more source
info)

Example input:

  List/*<T>*/ func/*<T>*/(List/*<T>*/ items, dynamic/*=T*/ seed)
  class Foo<T> {
    int i;
    static var x;
    Foo(this.i, o, {String v : "?"}) {}
  }

Output:
  function func<T>(items: core.List<T>, seed: T): core.List<T> {}
  const Foo$ = dart.generic(function(T) {
    class Foo<T> extends core.Object {
      i: number;
      static x;
      Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
        this.i = i;
      }
    }
    ...
    Foo.x = null;
    return Foo;
  });

Known remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports,
or we'll need a different temp + extra type annotations of the default-exported
object).

BUG=
==========

to

==========
Emit TypeScript / Closure ES6_TYPED type annotations in --closure mode (instead
of closure comments).

- Replaced ClosureType by a general JS.TypeRef, used in AST for identifier
types, return types
- Convert DartType to JS.TypeRef (in mixin JsTypeRefCodegen), including type
parameters (also added to AST in Fun & ClassExpression)
- Emit field declarations expected by TS
- Wrote a TypeScriptTypePrinter (mixed in by Printer) and a ClosureTypePrinter
(might disappear soon)
- Simplified annotation code, called in more places (seems to gives more source
info)

Example input:

  List/*<T>*/ func/*<T>*/(List/*<T>*/ items, dynamic/*=T*/ seed)
  class Foo<T> {
    int i;
    static var x;
    Foo(this.i, o, {String v : "?"}) {}
  }

Output:
  function func<T>(items: core.List<T>, seed: T): core.List<T> {}
  const Foo$ = dart.generic(function(T) {
    class Foo<T> extends core.Object {
      i: number;
      static x;
      Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
        this.i = i;
      }
    }
    ...
    Foo.x = null;
    return Foo;
  });

Known remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports,
or we'll need a different temp + extra type annotations of the default-exported
object).
- Generic type is currently locked inside the generic call. Might be able to
solve by exporting signatures in .d.ts file, or changing the way we do generics.

BUG=
==========

[Jennifer Messerly, 2016-02-09 00:39:08]

On 2016/02/05 22:03:37, ochafik wrote:
> Hi guys, here's a timid attempt to bring TypeScript annotations to our AST.
> 
> The output matches what (latest) TypeScript & Closure (with
> --language_in=ES6_TYPED) expect, with some limitations (listed in the cl's
> description).

Just a quick note that:

> function func<T>(items: core.List<T>, seed: T): core.List<T> {}

Won't be right once we have generic methods implemented in DDC. We'll need to
reify the type for soundness, so those methods will look similar to generic
classes:

function func(T) {
  return (items, seed) => {
    ... method body ...
  };
}


Generic method would look something like:

let Iterable = dart.generic(function(T) {
  class Iterable {
    map(S) {
      return (fn) => new (MappedIterable(S))(fn);
    }
  }
  return Iterable;
}


(Aside, we've had discussions about simplifying things to avoid the
"dart.generic" call. It's for canonicalization, but maybe we don't need that.)

But I'll take a look at this CL now, since we don't implement generic methods it
couldn't have regressed anything yet. :-)

[Jennifer Messerly, 2016-02-09 01:21:34]

I'll keep looking at this but wanted to send a few preliminary comments your
way.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.dart
File lib/src/js/js_types.dart (right):

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:1: // Copyright (c) 2012, the Dart project authors. 
Please see the AUTHORS file
2016? :)

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:11: /// JavaScript type reference.
It'd be good to add more info here. Like maybe a quick reference of what we
support in JS syntax. Maybe a link to corresponding closure/typescript/es7+
specs/docs/etc. Whatever you used to determine the set of nodes.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:13: static final _namedCache = <String, TypeRef>{};
Is this an optimization or is canonicalization a requirement for semantics?

If it's an optimization, I'd be tempted to leave it off until we know we need
it. In general, global hashmaps are a little scary, especially if they only
grow.

If you need to canonicalize for correctness, it's usually nice to have a
TypeProvider or something like that, which will handle the canonicalization for
you.

Another way this can happen, is always look up the typeref, given some other
unique identifier(s), in your universe of types. That way canonicalization tends
to happen. For example, in Dart Analyzer, given an AST node for TypeName "Foo",
they will look up in the current name scopes and find the ClassElement
corresponding to "Foo". There's only one unique ClassElement for that class, so
you'll always get the same one (assuming that is what "Foo" refers to in your
scope.)

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:15: int get precedenceLevel => EXPRESSION;
this seems like a really low precedence. I'd expect this to be higher in most
cases?

It doesn't really matter if you don't have parser support, but still, PRIMARY
precedence (like identifiers) is probably a better default. We'd want a slightly
lower level for the <> on generics.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:17: TypeRef();
Is this needed? I think you'll get it for free

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:31: elementType == null ? new TypeRef.named('Array') :
new ArrayTypeRef(elementType);
long line

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:40: factory TypeRef.function([TypeRef returnType,
Map<Identifier, TypeRef> paramTypes]) =>
long line here too

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/nodes.dart
File lib/src/js/nodes.dart (right):

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/nodes.dart#...
lib/src/js/nodes.dart:1142: /// For TypeScript / Closure's ES6_TYPED.
Maybe:

/// Type parameters passed to this generic function, if any.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/nodes.dart#...
lib/src/js/nodes.dart:1143: List<Identifier> get typeArgs;
These are type parameters, right? I'd suggest naming it `typeParams`.

(aside: at some point we should probably bring JS_AST up to the style guide, and
not use abbreviations. Not now though. ;) )


I think JS_AST might use FunctionExpression for both arrow functions:

    <T>(x) => x

and for declarations:

    function foo<T>(x : T) : T {
    }

Do they all support type parameters? If not, you may want to move this to a
subclass or to NamedFunction.

That said it might be fine here, depending on what TypeScript/Closure supports.

BTW, does TypeScript/Closure support constraints on the generic, like `T extends
Foo`?
it looks like TypeScript does:
http://www.typescriptlang.org/Handbook#generics-generic-constraints

so it probably shouldn't be an identifier.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/nodes.dart#...
lib/src/js/nodes.dart:1144: /// For TypeScript / Closure's ES6_TYPED.
/// The return type of the function, if any.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/nodes.dart#...
lib/src/js/nodes.dart:1151: final List<Identifier> typeArgs;
Not for now, but, what do you think about using @override?

I like it as a signal for "this already has documentation above".

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/nodes.dart#...
lib/src/js/nodes.dart:1468: /// For TypeScript / Closure's ES6_TYPED.
(Same comment -- I think we should give this a proper doc comment.)

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/nodes.dart#...
lib/src/js/nodes.dart:1474: [this.typeArgs = const [], this.fields = const []]);
I think it'd be fine to use a normal list. In general, we don't really use
immutable lists in js_ast, instead they're immutable by convention.

(At some point switching to BuiltList is probably a good idea.)

BTW: would this be worth named args? They're easier to version. Positional
optional args are only good if you know you won't ever want to add a named one
:)

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/printer.dart
File lib/src/js/printer.dart (right):

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/printer.dar...
lib/src/js/printer.dart:12: final bool printTypes;
this sounds like a method name. Maybe "shouldPrintTypes" so it will read like
`if (options.shouldPrintTypes)`? Other ideas are "shouldOutputTypes" or
"shouldEmitTypes" in place of "print", since the class name contains print. Even
"includeTypes" might work `if (options.includeTypes) { ... }`


Up to you tho

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/printer.dar...
lib/src/js/printer.dart:57: class Printer extends TypeScriptTypePrinter
implements NodeVisitor {
Hmmm. I haven't seen the other class yet, but this inheritance direction feels
backwards :)
This is begging for a comment at least :)

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/printer.dar...
lib/src/js/printer.dart:1083: if (options.printTypes && typeArgs != null &&
typeArgs.isNotEmpty) {
null check on variable/param is probably fastest, so if you wanted to put it
first, that'd probably be best

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/printer.dar...
lib/src/js/printer.dart:1084: out("<");
does typescript have any cases where precedence could matter?

I know in Dart we had an odd corner case:

    f(a < b, c >( d ));

That could be interpreted as:

// generic function call "a" with type args <b,c> and argument d
f( (a<b,c>) (  d  ) );

or as:

// call "f" with two arguments, a<b and c>d
f( (a < b),  (c > (d)) );

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/printer.dar...
lib/src/js/printer.dart:1349: if (!options.printTypes || node == null ||
node.isUnknown) return;
silly micro opt: check null first

[Jennifer Messerly, 2016-02-09 16:41:58]

Few more comments but LGTM. Since we're split across an ocean figured I'd ask a
lot of questions and brainstorm a bit on API design and such :). None of these
need to hold up landing your patch though.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.dart
File lib/src/js/js_types.dart (right):

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:28: : new GenericTypeRef(rawType, typeParams.toList());
looking at these factories again ... I'd probably put the burden on whoever
creates them to follow the right invariants. For example,  GenericTypeRef can
assert* that it gets non-empty type params.

Otherwise, you can't depend on getting a particular return type back. Seems like
it would encourage fairly dynamic code w/ downcasts.

that said it's just a hunch.

(* "assert" as in, a logical assertion. It may be better to use `if (...) throw
ArgumentError` instead of Dart's `assert` statement. Up to you. I think js_ast
mostly follows an `assert` pattern but I may be wrong there)

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:31: elementType == null ? new TypeRef.named('Array') :
new ArrayTypeRef(elementType);
On 2016/02/09 01:21:33, John Messerly wrote:
> long line

Another thought here. I noticed in the printing code for typerefs, you're
handling ArrayTypeRef with null elementType (prints as 'Array'). It seems good
to be consistent: either should always be ArrayTypeRef(null) or it should always
be TypeRef.named('Array').

I think I'd lean a bit towards ArrayTypeRef w/ null elementType. That way when
you make an array type, you don't have to know that 'Array' is a special case,
and your `new ArrayTypeRef` constructor will give you the right Dart object type
(ArrayTypeRef).

I can see how that's a harder call for things like TypeRef.object, below.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/type_printe...
File lib/src/js/type_printer.dart (right):

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/type_printe...
lib/src/js/type_printer.dart:1: // Copyright (c) 2012, the Dart project authors.
 Please see the AUTHORS file
2016? :)

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/type_printe...
lib/src/js/type_printer.dart:11: outSeparated(String separator, Iterable items,
[action(dynamic item)]) {
void ?

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/type_printe...
lib/src/js/type_printer.dart:24: outTypeParams(Iterable<TypeRef> typeParams) {
void ?

https://codereview.chromium.org/1676463002/diff/180001/test/codegen/expect/cl...
File test/codegen/expect/closure.js (right):

https://codereview.chromium.org/1676463002/diff/180001/test/codegen/expect/cl...
test/codegen/expect/closure.js:6: function generic_function<T>(items:
core.List<T>, seed: T): core.List<T> {
As noted ... this will change, a bit. It'll look a bit more like classes, with
an outer function(T) and an inner function<T>. Dart semantics are likely to
require reification. :|

That said, we could implement it under a reifyGenericFuncTypeArgs flag or
something like that. Defaults to On in normal mode, but closure/typescript mode
could turn off if they want. Probably should have a flag for classes too.

(At least at first, Dart VM will just have parsing support, so it wouldn't be
too inconsistent.)

https://codereview.chromium.org/1676463002/diff/180001/test/codegen/expect/cl...
test/codegen/expect/closure.js:14: class Foo<T> extends core.Object {
super awesome

https://codereview.chromium.org/1676463002/diff/180001/test/codegen_test.dart
File test/codegen_test.dart (right):

https://codereview.chromium.org/1676463002/diff/180001/test/codegen_test.dart...
test/codegen_test.dart:150: // TODO(jmesserly): this was added to get some
coverage of source maps
This TODO is getting more relevant over time eh? :)

What do you think about putting comments at the start of the test file? That's
the V8 trick (and C# too, IIRC). For example:

    // ddc flags: --closure

If that sounds good I can send a CL your way.

The benefit is you won't have to keep editing codegen_test for each new test
that you want to add that has options.

[Jennifer Messerly, 2016-02-09 16:42:54]

And I'm happy to take another look too if it would be helpful. :)

[ochafik, 2016-02-10 18:12:46]

Thanks a lot John!

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.dart
File lib/src/js/js_types.dart (right):

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:1: // Copyright (c) 2012, the Dart project authors. 
Please see the AUTHORS file
On 2016/02/09 01:21:33, John Messerly wrote:
> 2016? :)

Time flies!

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:11: /// JavaScript type reference.
On 2016/02/09 01:21:33, John Messerly wrote:
> It'd be good to add more info here. Like maybe a quick reference of what we
> support in JS syntax. Maybe a link to corresponding closure/typescript/es7+
> specs/docs/etc. Whatever you used to determine the set of nodes.

Done.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:13: static final _namedCache = <String, TypeRef>{};
On 2016/02/09 01:21:33, John Messerly wrote:
> Is this an optimization or is canonicalization a requirement for semantics?
> 
> If it's an optimization, I'd be tempted to leave it off until we know we need
> it. In general, global hashmaps are a little scary, especially if they only
> grow.
> 
> If you need to canonicalize for correctness, it's usually nice to have a
> TypeProvider or something like that, which will handle the canonicalization
for
> you.
> 
> Another way this can happen, is always look up the typeref, given some other
> unique identifier(s), in your universe of types. That way canonicalization
tends
> to happen. For example, in Dart Analyzer, given an AST node for TypeName
"Foo",
> they will look up in the current name scopes and find the ClassElement
> corresponding to "Foo". There's only one unique ClassElement for that class,
so
> you'll always get the same one (assuming that is what "Foo" refers to in your
> scope.)

Dropped the premature opt, I'm not testing for type identities

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:15: int get precedenceLevel => EXPRESSION;
On 2016/02/09 01:21:33, John Messerly wrote:
> this seems like a really low precedence. I'd expect this to be higher in most
> cases?
> 
> It doesn't really matter if you don't have parser support, but still, PRIMARY
> precedence (like identifiers) is probably a better default. We'd want a
slightly
> lower level for the <> on generics.

Done.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:17: TypeRef();
On 2016/02/09 01:21:33, John Messerly wrote:
> Is this needed? I think you'll get it for free

As soon as there's a factory ctor, seems we don't get the default ctor for free:

class Foo {
  factory Foo.bar() => new Foo(); // The class 'Foo' does not have a default
constructor
}

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:28: : new GenericTypeRef(rawType, typeParams.toList());
On 2016/02/09 16:41:57, John Messerly wrote:
> looking at these factories again ... I'd probably put the burden on whoever
> creates them to follow the right invariants. For example,  GenericTypeRef can
> assert* that it gets non-empty type params.
> 
> Otherwise, you can't depend on getting a particular return type back. Seems
like
> it would encourage fairly dynamic code w/ downcasts.
> 
> that said it's just a hunch.
> 
> (* "assert" as in, a logical assertion. It may be better to use `if (...)
throw
> ArgumentError` instead of Dart's `assert` statement. Up to you. I think js_ast
> mostly follows an `assert` pattern but I may be wrong there)

Done.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:31: elementType == null ? new TypeRef.named('Array') :
new ArrayTypeRef(elementType);
On 2016/02/09 16:41:57, John Messerly wrote:
> On 2016/02/09 01:21:33, John Messerly wrote:
> > long line
> 
> Another thought here. I noticed in the printing code for typerefs, you're
> handling ArrayTypeRef with null elementType (prints as 'Array'). It seems good
> to be consistent: either should always be ArrayTypeRef(null) or it should
always
> be TypeRef.named('Array').
> 
> I think I'd lean a bit towards ArrayTypeRef w/ null elementType. That way when
> you make an array type, you don't have to know that 'Array' is a special case,
> and your `new ArrayTypeRef` constructor will give you the right Dart object
type
> (ArrayTypeRef).
> 
> I can see how that's a harder call for things like TypeRef.object, below.

Done for Array & Function. Left a TODO for object (in TS, "there's more than one
way to do it")

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:31: elementType == null ? new TypeRef.named('Array') :
new ArrayTypeRef(elementType);
On 2016/02/09 01:21:33, John Messerly wrote:
> long line

Done.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/js_types.da...
lib/src/js/js_types.dart:40: factory TypeRef.function([TypeRef returnType,
Map<Identifier, TypeRef> paramTypes]) =>
On 2016/02/09 01:21:33, John Messerly wrote:
> long line here too

Sorry, formatter strangely didn't tackle that one...

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/nodes.dart
File lib/src/js/nodes.dart (right):

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/nodes.dart#...
lib/src/js/nodes.dart:1142: /// For TypeScript / Closure's ES6_TYPED.
On 2016/02/09 01:21:33, John Messerly wrote:
> Maybe:
> 
> /// Type parameters passed to this generic function, if any.

Done.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/nodes.dart#...
lib/src/js/nodes.dart:1143: List<Identifier> get typeArgs;
On 2016/02/09 01:21:33, John Messerly wrote:
> These are type parameters, right? I'd suggest naming it `typeParams`.
> 
> (aside: at some point we should probably bring JS_AST up to the style guide,
and
> not use abbreviations. Not now though. ;) )
> 
> 
> I think JS_AST might use FunctionExpression for both arrow functions:
> 
>     <T>(x) => x
> 
> and for declarations:
> 
>     function foo<T>(x : T) : T {
>     }
> 
> Do they all support type parameters? If not, you may want to move this to a
> subclass or to NamedFunction.

Both kinds of generic functions are valid TS / ES6_TYPED (isn't it neat?)

> BTW, does TypeScript/Closure support constraints on the generic, like `T
extends
> Foo`?
> it looks like TypeScript does:
> http://www.typescriptlang.org/Handbook#generics-generic-constraints
> 
> so it probably shouldn't be an identifier.

Ouch, indeed... will leave a TODO if that's okay for now... (btw, would it be
worth decoupling Identifier from Parameter, if we introduce a TypeParameter?
Could simplify some of the declaration visitors I think)

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/nodes.dart#...
lib/src/js/nodes.dart:1144: /// For TypeScript / Closure's ES6_TYPED.
On 2016/02/09 01:21:33, John Messerly wrote:
> /// The return type of the function, if any.

Done.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/nodes.dart#...
lib/src/js/nodes.dart:1151: final List<Identifier> typeArgs;
On 2016/02/09 01:21:33, John Messerly wrote:
> Not for now, but, what do you think about using @override?
> 
> I like it as a signal for "this already has documentation above".

I love @override, so since you mentioned it... done. (we'd need a cleanup pass
in the visitors... and maybe a hint from the analyzer when it's missing, as in
Java?)

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/nodes.dart#...
lib/src/js/nodes.dart:1468: /// For TypeScript / Closure's ES6_TYPED.
On 2016/02/09 01:21:33, John Messerly wrote:
> (Same comment -- I think we should give this a proper doc comment.)

Done.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/nodes.dart#...
lib/src/js/nodes.dart:1474: [this.typeArgs = const [], this.fields = const []]);
On 2016/02/09 01:21:33, John Messerly wrote:
> I think it'd be fine to use a normal list. In general, we don't really use
> immutable lists in js_ast, instead they're immutable by convention.
> 
> (At some point switching to BuiltList is probably a good idea.)
> 
> BTW: would this be worth named args? They're easier to version. Positional
> optional args are only good if you know you won't ever want to add a named one
> :)

Done.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/printer.dart
File lib/src/js/printer.dart (right):

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/printer.dar...
lib/src/js/printer.dart:12: final bool printTypes;
On 2016/02/09 01:21:33, John Messerly wrote:
> this sounds like a method name. Maybe "shouldPrintTypes" so it will read like
> `if (options.shouldPrintTypes)`? Other ideas are "shouldOutputTypes" or
> "shouldEmitTypes" in place of "print", since the class name contains print.
Even
> "includeTypes" might work `if (options.includeTypes) { ... }`
> 
> 
> Up to you tho

Thanks, went for shouldEmitTypes

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/printer.dar...
lib/src/js/printer.dart:57: class Printer extends TypeScriptTypePrinter
implements NodeVisitor {
On 2016/02/09 01:21:34, John Messerly wrote:
> Hmmm. I haven't seen the other class yet, but this inheritance direction feels
> backwards :)
> This is begging for a comment at least :)

Good point, left a TODO for when/if we drop ClosureTypePrinter.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/printer.dar...
lib/src/js/printer.dart:1083: if (options.printTypes && typeArgs != null &&
typeArgs.isNotEmpty) {
On 2016/02/09 01:21:33, John Messerly wrote:
> null check on variable/param is probably fastest, so if you wanted to put it
> first, that'd probably be best

Done.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/printer.dar...
lib/src/js/printer.dart:1084: out("<");
On 2016/02/09 01:21:33, John Messerly wrote:
> does typescript have any cases where precedence could matter?
> 
> I know in Dart we had an odd corner case:
> 
>     f(a < b, c >( d ));
> 
> That could be interpreted as:
> 
> // generic function call "a" with type args <b,c> and argument d
> f( (a<b,c>) (  d  ) );
> 
> or as:
> 
> // call "f" with two arguments, a<b and c>d
> f( (a < b),  (c > (d)) );
> 

It *looks* fine in TS (since the : would announce a switch to type space: `f(a:
< b, c >( d ) => number)`), but left a TODO in outTypeParams to reconsider when
we start emitting type params expressions (generic method call, etc).

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/printer.dar...
lib/src/js/printer.dart:1349: if (!options.printTypes || node == null ||
node.isUnknown) return;
On 2016/02/09 01:21:33, John Messerly wrote:
> silly micro opt: check null first

Done.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/type_printe...
File lib/src/js/type_printer.dart (right):

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/type_printe...
lib/src/js/type_printer.dart:1: // Copyright (c) 2012, the Dart project authors.
 Please see the AUTHORS file
On 2016/02/09 16:41:57, John Messerly wrote:
> 2016? :)

Done.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/type_printe...
lib/src/js/type_printer.dart:11: outSeparated(String separator, Iterable items,
[action(dynamic item)]) {
On 2016/02/09 16:41:58, John Messerly wrote:
> void ?

Done.

https://codereview.chromium.org/1676463002/diff/180001/lib/src/js/type_printe...
lib/src/js/type_printer.dart:24: outTypeParams(Iterable<TypeRef> typeParams) {
On 2016/02/09 16:41:58, John Messerly wrote:
> void ?

Done.

https://codereview.chromium.org/1676463002/diff/180001/test/codegen/expect/cl...
File test/codegen/expect/closure.js (right):

https://codereview.chromium.org/1676463002/diff/180001/test/codegen/expect/cl...
test/codegen/expect/closure.js:6: function generic_function<T>(items:
core.List<T>, seed: T): core.List<T> {
On 2016/02/09 16:41:58, John Messerly wrote:
> As noted ... this will change, a bit. It'll look a bit more like classes, with
> an outer function(T) and an inner function<T>. Dart semantics are likely to
> require reification. :|
> 
> That said, we could implement it under a reifyGenericFuncTypeArgs flag or
> something like that. Defaults to On in normal mode, but closure/typescript
mode
> could turn off if they want. Probably should have a flag for classes too.
> 
> (At least at first, Dart VM will just have parsing support, so it wouldn't be
> too inconsistent.)

+1 for reifyGenericFuncTypeArgs
And maybe even a dontReifyGenericClassTypeArgs in the future? :-D

https://codereview.chromium.org/1676463002/diff/180001/test/codegen/expect/cl...
test/codegen/expect/closure.js:14: class Foo<T> extends core.Object {
On 2016/02/09 16:41:58, John Messerly wrote:
> super awesome

Hehe, it's only locally awesome, doesn't break out of the generic call yet...

https://codereview.chromium.org/1676463002/diff/180001/test/codegen_test.dart
File test/codegen_test.dart (right):

https://codereview.chromium.org/1676463002/diff/180001/test/codegen_test.dart...
test/codegen_test.dart:150: // TODO(jmesserly): this was added to get some
coverage of source maps
On 2016/02/09 16:41:58, John Messerly wrote:
> This TODO is getting more relevant over time eh? :)
> 
> What do you think about putting comments at the start of the test file? That's
> the V8 trick (and C# too, IIRC). For example:
> 
>     // ddc flags: --closure
> 
> If that sounds good I can send a CL your way.
> 
> The benefit is you won't have to keep editing codegen_test for each new test
> that you want to add that has options.

Yes please, would be awesome! (sorry for letting these hacks grow this big :-))

[ochafik, 2016-02-10 18:13:10]

Description was changed from

==========
Emit TypeScript / Closure ES6_TYPED type annotations in --closure mode (instead
of closure comments).

- Replaced ClosureType by a general JS.TypeRef, used in AST for identifier
types, return types
- Convert DartType to JS.TypeRef (in mixin JsTypeRefCodegen), including type
parameters (also added to AST in Fun & ClassExpression)
- Emit field declarations expected by TS
- Wrote a TypeScriptTypePrinter (mixed in by Printer) and a ClosureTypePrinter
(might disappear soon)
- Simplified annotation code, called in more places (seems to gives more source
info)

Example input:

  List/*<T>*/ func/*<T>*/(List/*<T>*/ items, dynamic/*=T*/ seed)
  class Foo<T> {
    int i;
    static var x;
    Foo(this.i, o, {String v : "?"}) {}
  }

Output:
  function func<T>(items: core.List<T>, seed: T): core.List<T> {}
  const Foo$ = dart.generic(function(T) {
    class Foo<T> extends core.Object {
      i: number;
      static x;
      Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
        this.i = i;
      }
    }
    ...
    Foo.x = null;
    return Foo;
  });

Known remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports,
or we'll need a different temp + extra type annotations of the default-exported
object).
- Generic type is currently locked inside the generic call. Might be able to
solve by exporting signatures in .d.ts file, or changing the way we do generics.

BUG=
==========

to

==========
Emit TypeScript / Closure ES6_TYPED type annotations in --closure mode (instead
of closure comments).

- Replaced ClosureType by a general JS.TypeRef, used in AST for identifier
types, return types
- Convert DartType to JS.TypeRef (in mixin JsTypeRefCodegen), including type
parameters (also added to AST in Fun & ClassExpression)
- Emit field declarations expected by TS
- Wrote a TypeScriptTypePrinter (mixed in by Printer) and a ClosureTypePrinter
(might disappear soon)
- Simplified annotation code, called in more places (seems to gives more source
info)

Example input:

  List/*<T>*/ func/*<T>*/(List/*<T>*/ items, dynamic/*=T*/ seed) {}

  class Foo<T> {
    int i;
    static var x;
    Foo(this.i, o, {String v : "?"}) {}
  }

Output:

  function func<T>(items: core.List<T>, seed: T): core.List<T> {}

  const Foo$ = dart.generic(function(T) {
    class Foo<T> extends core.Object {
      i: number;
      static x;
      Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
        this.i = i;
      }
    }
    ...
    Foo.x = null;
    return Foo;
  });

Known remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports,
or we'll need a different temp + extra type annotations of the default-exported
object).
- Generic type is currently locked inside the generic call. Might be able to
solve by exporting signatures in .d.ts file, or changing the way we do generics.

BUG=
==========

[ochafik, 2016-02-10 18:22:25]

Description was changed from

==========
Emit TypeScript / Closure ES6_TYPED type annotations in --closure mode (instead
of closure comments).

- Replaced ClosureType by a general JS.TypeRef, used in AST for identifier
types, return types
- Convert DartType to JS.TypeRef (in mixin JsTypeRefCodegen), including type
parameters (also added to AST in Fun & ClassExpression)
- Emit field declarations expected by TS
- Wrote a TypeScriptTypePrinter (mixed in by Printer) and a ClosureTypePrinter
(might disappear soon)
- Simplified annotation code, called in more places (seems to gives more source
info)

Example input:

  List/*<T>*/ func/*<T>*/(List/*<T>*/ items, dynamic/*=T*/ seed) {}

  class Foo<T> {
    int i;
    static var x;
    Foo(this.i, o, {String v : "?"}) {}
  }

Output:

  function func<T>(items: core.List<T>, seed: T): core.List<T> {}

  const Foo$ = dart.generic(function(T) {
    class Foo<T> extends core.Object {
      i: number;
      static x;
      Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
        this.i = i;
      }
    }
    ...
    Foo.x = null;
    return Foo;
  });

Known remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports,
or we'll need a different temp + extra type annotations of the default-exported
object).
- Generic type is currently locked inside the generic call. Might be able to
solve by exporting signatures in .d.ts file, or changing the way we do generics.

BUG=
==========

to

==========
Emit TypeScript / Closure ES6_TYPED type annotations in --closure mode (instead
of closure comments).

- Replaced ClosureType by a general JS.TypeRef, used in AST for identifier
types, return types
- Convert DartType to JS.TypeRef (in mixin JsTypeRefCodegen), including type
parameters (also added to AST in Fun & ClassExpression)
- Emit field declarations expected by TS
- Wrote a TypeScriptTypePrinter (mixed in by Printer) and a ClosureTypePrinter
(might disappear soon)
- Simplified annotation code, called in more places (seems to gives more source
info)

Example input:

  List/*<T>*/ func/*<T>*/(List/*<T>*/ items, dynamic/*=T*/ seed) {}

  class Foo<T> {
    int i;
    static var x;
    Foo(this.i, o, {String v : "?"}) {}
  }

Output:

  function func<T>(items: core.List<T>, seed: T): core.List<T> {}

  const Foo$ = dart.generic(function(T) {
    class Foo<T> extends core.Object {
      i: number;
      static x;
      Foo(i: number, o, {v = "?"}: {v?: string} = {}) {
        this.i = i;
      }
    }
    ...
    Foo.x = null;
    return Foo;
  });

Known remaining issues:
- typedefs expect a `type Callback = (...) => ...;` statement
- `exports` is a reserved keyword in TS (either we change the way we do exports,
or we'll need a different temp + extra type annotations of the default-exported
object).
- Generic type is currently locked inside the generic call. Might be able to
solve by exporting signatures in .d.ts file, or changing the way we do generics.

BUG=
R=jmesserly@google.com

Committed:
https://github.com/dart-lang/dev_compiler/commit/2b3823f4a9309c23b0b1d1c0faa3...
==========

[ochafik, 2016-02-10 18:22:27]

Committed patchset #9 (id:300001) manually as
2b3823f4a9309c23b0b1d1c0faa31df5f9a24c54 (presubmit successful).