As part of this change I made codegen synchronous. Technically is not necessary,
but I think it reduces complexity a lot. For example, keeping it async would
have required more changes to the testing infrastructure. Let me know if you
want to keep that change separate though.
With this change, I'm removing one more use of element.node, which is necessary
to achileve our goal. There is only one more use of this API, for which John has
a CL out.
BUG=
R=jmesserly@google.com
Review URL: https://chromereviews.googleplex.com/145167013
also correctly exports the values of top-level fields, and ensures it uses the most up-to-date value for mutable top-level fields
we can likely improve this further once we have ES6 modules, but it seems like an okay start
R=sigmund@google.com
Review URL: https://chromereviews.googleplex.com/147927013
This CL fixes a bug in the coercion reifier in which a null value would get wrapped by the reifier, turning it into a non-null value.
There are also some small fixes for some types from the DownCastBase refactoring which weren't quite right.
BUG=
R=vsm@google.com
Review URL: https://chromereviews.googleplex.com/140327013
A couple places remain:
* how codegen is driven (we should change the pipeline for this)
* how js-codegen determines whether an top-level expression is a constant field
(this might require tracking additional information in our checker)
R=leafp@google.com
Review URL: https://chromereviews.googleplex.com/143177014
This is very half baked. Putting it down to work on better type literal support for the moment.
Qs:
(1) What should we measure? cast failures mapped back to source? I don't think we inject anything else right now.
(2) How should we report? I just have dump function right now, but that'll be unwieldy on large apps.
R=jacobr@google.com, jmesserly@google.com
Review URL: https://chromereviews.googleplex.com/146737013
We'll need to figure out an efficient way to do this in JS output.
An alternative, suggested by Jacob, is only provide something like an applyTruncated function. E.g., something like:
dynamic applyTruncated(Function f, List args) {
var arity = getArity(f);
assert(args.length >= arity.min);
args = args.sublist(0, arity.max);
return Function.apply(f, args);
}
Jacob: is this what you have in mind?
If so, we could *only* provide this. The dart2j impl could use the existing code pattern of is-checks. The ddc implementation could map to JS apply (with a check for named params?).
Thoughts?
R=jacobr@google.com
Review URL: https://chromereviews.googleplex.com/137047014
- DownCastExact : Cases where the static type of rhs is exact
List<int> l = [1, 2, 3];
- DownCastDynamic : Cases where the static type of the rhs is a subtype (in Dart) of the static type of lhs:
List l = ...;
List<int> l2 = l;
R=jacobr@google.com
Review URL: https://chromereviews.googleplex.com/141647013
This CL adds a general reification pass which makes abstract coercions concrete by modifiying the ast. Casts are reified as "as" expressions, and wrappers are reified by creating functions which take the old function as arguments and produce a new wrapped function. There are a number of known issues not yet addressed:
1) No distinction between dart "as" and our special "as" is made yet.
2) Wrapper generation functions do not check for null arguments yet.
3) Types introduced via wrappers and "as" expressions are not yet added to the set of types for which new imports may be required.
4) Wrapper functions for non-literals can't be guaranteed not to change the runtime type without more backend support, since we only have their static type.
This CL also adds support for rewriting import directives in the dart backend to reflect the directory structure that we currently use for output. Probably this should be rethought. Currently I just use absolute file URIs, which is not what we want.
This CL also adds support for adding in the import directives needed to account for type names added via inference. This is not yet correct for "part of" files, since we need to add the imports to the main library file.
BUG=
R=vsm@google.com
Review URL: https://chromereviews.googleplex.com/137957013
John Messerly