This change removes functionality that is not part of the core Dart Dev
Compiler, in particular those features that were not designed for
incremental/modular compilation.
For a while, the primary way to use DDC will be as a compiler invoked by
a build system, e.g. make or bazel or some node.js based-build system.
We'd love to see the user functionality provided by these return.
In particular, a well designed server+watcher system would be a huge
boost to productivity!
I'll see about moving over HTML reporting to Analyzer CLI. It has a lovely UI.
Thanks to everyone who contributed these features.
The following features were removed:
* DDC transformer. Transformers require whole world, in memory files.
* DDC server. The server has its own mini-build system.
* Various kinds of reporting. These should be moved to Analyzer CLI.
Note: batch compiler and the node runner are left for now.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1788973002 .
- 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 .
- 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 .
Known issues:
- Import syntax: using 'dart/core' right now, but should be
'./dart/core' or something else?
- _jsModuleValue not supported in es6 output yet (how is it meant to be
used?)
BUG=
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1612083002 .
This:
- Ensures that a given AST is processed once per context, avoiding AST caching issues and redundant work
- Associates file errors with their library instead of the entry point - we now only generate these once across different entry points
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1376123004 .
this also implements multitest support, which fixes#280
Fixes some other preexisting bugs:
* MetaLets did not simplify themselves correctly in some nested cases
* Library prefixed identifiers did not work as lvalues in opassign
* dsetindex/dput/[]= methods did not return a value
* checker did not correctly handle invalid constructor field initializers
* cascades did not correctly work with method invocations(?)
* postfix ++/-- did not correctly generate lvalues in some cases
The good news: because this reuses on our existing lvalue/metalet helpers, it managed to flush out a lot of bugs in other features that use them.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1316723003 .
we already have to review them, so running a diff and failing the rest of the test pass seems unhelpful. Instead operate like our generated SDK does, and update in place
R=vsm@google.com
Review URL: https://codereview.chromium.org/1188173003.
Hook the coercion reifier into the JS backend.
The principle observed changes in the output are from the downward type inference eliminating casts.
The coercion reifier changes in this CL in two ways.
The first is a relatively minor change to factor out the instrumented runtime calls. The reifier is now parameterized by a runtime object. If present, casts, wraps, and type object creation are delegated to the runtime. Otherwise the reifier just produces cast objects directly. The JS codegen always does the latter.
The larger change is an attempt to make the new AST nodes be resolved. This is principally done for the typedefs produced for casts - we're not using wrapping right now so I've left that for future if we want it. This is a bit painful - if we continue down this path I think I'll want to factor this out into a ResolvedAstBuilder or somesuch, but for now this seems to be working.
The rest of the changes are just plumbing in the coercion reifier and its dependencies into the js backend.
BUG=
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1096583002
essentially verify the expected HTML in the test
this tripped on an interesting issue, we have two ways of computing MD5 hashes that produce different answers. I left that as a TODO.
R=jacobr@google.com
Review URL: https://codereview.chromium.org/1056613002
Now the HTML can include a hash in the URL for cachable resources, and the serve knows how to include cache-control headers.
In the process of doing so, I had to change a couple things that made it possible to fix#92 as well (producing different output in the command-line than in server mode).
R=vsm@google.com
Review URL: https://codereview.chromium.org/993213003
John Messerly