(Seems to make some sdk imports not lazy anymore, without even burning the house)
Also, tiny module-related fixes to help with some es6 tools such as rollup:
- Avoid self-importing in eager corelibOrder hack
- Always export exports in es6 module builder
BUG=
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1689013002 .
- 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
Review URL: https://codereview.chromium.org/1676463002 .
Note that pub get is needed after this.
When DDC works with analyzer@master, we can setup a travis env by adding the following lines to .travis.yml:
before_install:
- test -z "$ANALYZER_BRANCH" || ./tool/override_analyzer_dependency.sh
env:
- ANALYZER_BRANCH=""
- ANALYZER_BRANCH="master"
Currently the latest analyzer provides null elements for CompilationUnit parts of dart._runtime (see failure: https://travis-ci.org/dart-lang/dev_compiler/jobs/107936636#L465)
BUG=
R=leafp@google.com
Review URL: https://codereview.chromium.org/1682673002 .
- Force import order in all sdk files + simplify module builders
- Stub a node_test.sh with hello world + DeltaBlue (to be expanded to language tests in a followup change)
- Use global_ from dart:_runtime in html lib
- Better export for symbols that node chokes upon: throw, const, void, implements, export... (define as throw_ locally, with proper local resolution, then export as throw).
- Cleanup node module builder
BUG=
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1633003002 .
Within some AST context (at library granularity, for convenience), we
collect all the assignments to local vars:
- Declaration with no initializer amounts to `null` assignment
- Assignment ops are expanded naively: `x++` yield an assigned value of
`x + 1`, etc
We detect "trivially nullable" variables (e.g. `var x;`, `x =
breaking.out;`) by spotting assigned values that are nullable under the
optimistic assumption that all known variables are non-nullable.
Then we build a nullability dependency graph in linear time: whenever
we see `x = y;`, we know that "y is nullable" implies "x is nullable".
Finally, we propagate "trivial nullabilities" through that graph: any
variable that wasn't reached is deemed not-nullable.
(this is similar to mark and sweep garbage collection, where the roots
are the "trivially nullable" variables; credits to leafpetersen@ for
linear solution)
We're already serving sources from the original directory (for source
maps). This lets us serve other resources as well. Makes it simpler
to run angular todo and other apps with xhr'ed data.
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1644673002 .
mainly, this backs off of some readability optimizations around static and top-level fields that were too aggressive. On their own, they were okay, but they collide with the library-cycle issues. Once we can remove that issue, we could consider restoring some of this. In the meantime, simplicity is good.
The new operation in the declaration loader is to allow us to see if an initializer has all its dependencies satisfied, but without changing any ordering if they are not.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1636233002 .
vsmenon