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 .
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 .
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 .
function f(a, opts) {
let b = opts && 'b' in opts ? opts.b : null;
let c = opts && 'c' in opts ? opts.c : c_default;
...
After:
function f(a, {b = null, c = c_default} = {}) {
...
Note:
- Still reverting to old code when any parameter clashes with reserved JS names (see discussion in https://github.com/dart-lang/dev_compiler/issues/392)
- When a parameter clashes with a Object.prototype property, using a clean default opts value (Object.create(null)).
- Passing opts through in aliased constructors, both for speed/concision and correctness (since default param value semantic is weird there)
BUG=
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1484263002 .
This is WIP - not quite ready for review.
Not all tests are passing yet. Most checker and inference tests are passing, but about a quarter are failing - need to look.
The non-runtime changes under lib along with test/testing.dart are the only real changes.
We seem to be losing some type info - lots of new casts - but I see at least one removed.
R=brianwilkerson@google.com, jmesserly@google.com, leafp@google.com
Review URL: https://codereview.chromium.org/1355893003 .
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 .
Vijay Menon