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
JSTemporary is now identified by instance, not its String name. This provides enough information to do renaming correctly and avoid the bug in #136.
The namer now considers all scopes where the temporary is visible, and chooses a name that doesn't conflict with other identifiers. Because it only considers scopes where the temp appears, it does less renaming that the previous version.
other changes:
* adds _emitSend for more consistent emitting of method calls. can't be used everywhere yet, but it unifies some things
* more consistent use of the core.String.* static pattern
* fix dynamic invoke to private members
* fix implicit-this to use emitMemberName, which makes them work with extension methods
* build the global extension method table up-front and optimize lookups (method name first, then subtype test if needed)
* teach the compiler that IsExpression never returns null
R=jacobr@google.com
Review URL: https://codereview.chromium.org/1083763003
This is some first steps towards hooking the reifier into the js backend. I've made the reifier operate on whole libraries instead of per compilation unit so that it can be hoisted out as a separate pass. I changed the API of the reifier to return a map from new type identifiers to information about their library of origin, so that the code generators can deal with these appropriately. Take a look, see what you think - suggestions as to how to structure this to interact well with the JS backend welcome.
BUG=
R=jmesserly@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/1070453002
Simplifies js_codegen to remove the special cases for things like cascades and statement parent, instead these "fall out" of JSMetaLet node and the various to* methods in js_ast. As a result of handling things more uniformly, code gets cleaner in a lot of cases. One slight "regression" is a cascade at the end of a variable init list with multiple variables. But multiple variables aren't very common so doesn't seem worth optimizing readability there.
R=leafp@google.com, vsm@google.com
Review URL: https://codereview.chromium.org/1069493002
Notes:
- We probably should have a general type object class for all types. Just handling function types for now.
- Not yet encoding the type on functions during codegen ... falling back on arity effectively.
- typedefs are lazy to avoid ordering issues. Could perhaps reuse existing logic instead.
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1076883003
There is the separate, but related question of how to invoke Object
methods when the receiver is Object or a JS primitive. That should be
handled in the JS backend. I can tackle that next if no one else is.
See #98.
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1055923002
This changes the RestrictedTypeRules to eliminate a direct dependency on CheckerReporter. Instead of logging a missing type error with the reporter directly, it now calls an optional callback. The Checker registers an appropriate callback for its errors. Currently the code generators don't log these errors. This eliminates the dependency of the code generators on the checker reporter.
BUG=
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1067553004
During inference, allow sub-expressions of type dynamic to be cast to the inferred type.
This CL also adds special case support for the case where we are trying to infer a type for a closure literal with a fuzzy type - often these closures are already well-typed (or easily inferable) if we eliminate the fuzziness.
This gets rid of two of the static errors on angular hello world, along with most of the InferableClosure warnings (turning them into InferredTypeClosure infos).
Most of the remaining InferableClosure cases are function literals with block function bodies, which I don't handle in general yet.
BUG=
R=vsm@google.com
Review URL: https://codereview.chromium.org/1059763003
This records the actual point at which type inference fails and uses that to give a better error message. So where before we would say:
severe: line 76, column 38 of package:angular2/src/forms/directives.dart: [StaticTypeError] Type check failed: [c.validator, this.validator] (List<dynamic>) is not of type List<Function>
c.validator = validators.compose([c.validator, this.validator]);
we will now in addition say:
because c.validator cannot be typed as Function
BUG=
R=vsm@google.com
Review URL: https://codereview.chromium.org/1056183002
cleaner since we only worry about it in one place, and the "this" check is easier and more precise now.
incidentally, I saw a CL go by on the V8 bug, looks like it's close to being fixed
R=jacobr@google.com
Review URL: https://codereview.chromium.org/1052693004
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
This is a first cut at downwards inference. The interaction with InferableLiteral etc isn't well sorted out yet, so while downwards inference on nested expressions works, there will currently be spurious warnings.
BUG=
R=vsm@google.com
Review URL: https://codereview.chromium.org/1038213003
Leaf Petersen