A couple notes:
- regress_18535_test started failing at runtime. It's using unimplemented mirrors code, so perhaps a static failure before.
- typed_data_sublist_type_dart started failing at runtime. It was inferring Is<EfficientLength> with the type omitted. :-(
- my local chrome is newer than the one on travis failing on generators. not seeing that error.
TBR=jmesserly@google.com
Review URL: https://codereview.chromium.org/1847163002 .
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 .
* factor the class heritage workaround so it's out of the way & easier to remove later.
* always emit type parameters in the AST, and pass the flag to the printer to skip printing them.
* cleanup an unnecessary sync* method for closure field decls.
* also, reformats. I think I forgot to do that in previous CL.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1767803002 .
fixes https://github.com/dart-lang/dev_compiler/issues/471
Changes here are:
* Analyzer now infers list/map literals
* Analyzer changed how isPotentiallyMutated* APIs work, so we need to track current function
* Another fix to arrow functions. We shouldn't skip generating covariant arg checks. If there were any, we use `=> { block }` form rather than `=> expr` form.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1757343002 .
Some of the high level changes are:
* visit catch body, fixes#463
* handle temps created by the compiler. These were in some cases treated incorrectly as non-null (see tests diff)
* compute nullable in the same pass as visiting assignments
* simplify visiting += and ++, fix ++ (it was dead code, #463)
* simplify _isNullable
* if we fail to see a variable declaration, treat it as nullable
* stack trace in catch is treated as non-null
R=vsm@google.com
Review URL: https://codereview.chromium.org/1751963002 .
(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 .
- 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)
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 .
The following part files were ported from the original .js (lib/runtime/dart/_foo.js -> input_sdk/private/foo.dart):
- input_sdk/private/rtti.dart
- input_sdk/private/types.dart
- input_sdk/private/classes.dart
- input_sdk/private/errors.dart
- input_sdk/private/generators.dart
- input_sdk/private/operations.dart
- input_sdk/private/runtime.dart
Notes:
- Introduced genericTypeConstructor intrinsic: `JS('', '#(type)', genericTypeConstructor(List))` generates `core.List$(type)`
- Used new JS quasiquotes everywhere
- Depends on new internal `@JSExportName` annotation to alias symbols like dart.{as, is, const, assert, export, implements, throw, async, dynamic, void} (see https://codereview.chromium.org/1580413002/)
BUG=
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1530563003 .
This is so the Atom plugin doesn't need to regenerate the SDK (it still
needs to be compiled with --no-destructure-named-params, though, until
Atom is updated to more ES6-compliant node/Chrome).
Vijay Menon