This should help reviewers see how a change in type propagation affects
the current output.
There are currently only 3 tests with gold files. We can add more tests
ongoing as more features are implemented.
The expected outputs contains a lot of wrong types because the backing
type propagation is not complete.
BUG=
R=kustermann@google.com
Review URL: https://chromereviews.googleplex.com/440487013 .
For constructor bodies, we arbitrarily set the return type to 'void'.
Although there is hardly any legitimate use for the "return type" of
a constructor, this doesn't have any overhead and it simplifies the
restriction on FunctionNode.
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/446827013 .
To make this more digestible, a lot of things are intentionally left
out from the implementation:
- Some AST nodes, like super calls and await
- Handling of externals
- Avoidance of redundant variables in the constraint system
The solver is currently field-based, which is also something I plan to
change.
Suggested reading order:
- constraints.dart
- solver.dart
- canonicalizer.dart
- builder.dart
- visualizer.dart
R=kasperl@google.com
Review URL: https://chromereviews.googleplex.com/442937013 .
Previously, anonymous libraries would have an empty name when loaded
from Dart, but a null name when loaded from binary.
The textual printer will use synthetic names for null, but not for empty
names, so we should prefer null.
BUG=
R=kmillikin@google.com
Review URL: https://chromereviews.googleplex.com/419187013 .
If an index assignment occurs where its result is used, we bind
the value in a 'let' to reuse the value.
For example:
return x[y] = z
would become:
return let #x = x
in let #y = y
in #x.[]=(#y, z)
but now becomes:
return let #x = x
in let #y = y
in let #z = z
in let #dummy = #x.[]=(#y, #z)
in #z
It clearly looks worse, but it makes the semantics of MethodInvocation
node a lot more uniform when there is no special case for invoking a
method named '[]='.
Some analyses can perform special treatment of 'this' accesses, so we
should preserve them when desugaring.
For example:
this.foo += 1
would become:
let #1 = this in #1.foo = #1.foo.+(1)
but now instead becomes:
this.foo = this.foo.+(1)
Redirecting factories are desugared to a factory procedure with a
return and call in the body.
Constant calls to a constant redirecting factory are redirected at the
call-site to the effective target, which must be a constant constructor.
Asger Feldthaus