Before: constant-valued expressions were usually compiled by the JS constant
compiler task, which surprisingly produces a Dart (not JS) constant.
After: use the already computed constant value of a constant-valued
expression. This is looked up in one of two ways depending on whether the
expression is an identifier or not. For primitive constants (Booleans,
doubles, integers, strings, and null) simply construct them as they have not
had a value computed.
Also, fix a variety of small bugs. In some case the fix is disabling an
incorrect code path and bailing out of the compiler.
BUG=
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org//1057483004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45335 260f80e4-7a28-3924-810f-c04153c831b5
Throw and rethrow are implemented as CPS expressions in tail position.
The CPS translation assumes that all expressions translate to a primitive
that is the value of the expression, and throw is an expression in Dart.
For simplicity of the translation, a non-tail throw Primitive is sometimes
used as a placeholder during the translation and removed immediately
afterward.
Both throw and rethrow are represented in the Tree IR. In the Dart backend,
throw translates to throw and rethrow translates to rethrow. In the JS
backend, throw translates to JS throw of a wrapped value. Rethrow is not
currently implemented for the JS backend, it bails out of the compiler.
R=asgerf@google.com
BUG=
Review URL: https://codereview.chromium.org//1092023002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45235 260f80e4-7a28-3924-810f-c04153c831b5
The new flag --enable-debug-break turns the otherwise illegal Dart statement
break "message";
into a break instruction preceded with a debug message, the equivalent of
emitting an Assembler::Stop("message").
Add a language test expecting a syntax error without the flag.
Change expected break instruction in arm64 simulator.
Remove constants related to now deleted simulator tracing on mips and arm64.
R=johnmccutchan@google.com, srdjan@google.com
Review URL: https://codereview.chromium.org//1087383002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45218 260f80e4-7a28-3924-810f-c04153c831b5
The key change in this CL is to change the technique for avoiding
infinite recursion in the presence of illegal code. Rather than track
type pairs, we track (a) the function typedef elements that have been
expanded while examining the LHS and RHS, and (b) the class and type
parameter elements that have been visited while exploring the class
hierarchy. If a function typedef is encountered while expanding
itself, or a class or type parameter element is encountered while
searching its own class hierarchy, then it is skipped. Since both
class hierarchy loops and self-referential function typedefs are
prohibited by the spec, this ensures that the checks to avoid
recursion will only trigger in the presence of compile errors, so
analyzer will produce correct warnings in the absence of compile
errors.
As a consequence of the new technique, bugs 21912 and 22976 are fixed.
In addition, there are a few other improvements:
- Optional arguments are used to keep track of elements already
visited, so it's not necessary to have separate functions
isAssignableTo2, isSubtypeOf2, and isMoreSpecificThan2, nor do we
need "internal" versions of those functions.
- InterfaceTypeImpl no longer needs a special implementation of
isSubtypeOf. It's now implemented in the same way it's defined (in
terms of isMoreSpecificThan).
- Some flaws were discovered in the co19 tests. I've filed a co19 bug
for these, and updated the co19-analyzer2 status file.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1070443002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@44965 260f80e4-7a28-3924-810f-c04153c831b5
RegisterAllocator and CopyPropagator have been removed.
Variables are merged after StatementRewriter.
This simplifies CPS->Tree translation is a little bit since the mapping
to variables is one-to-one.
The StatementRewriter has a more SSA-like input, but has to be more
aggressive when looking for a redex. It now looks through a chain of
phi-assignments to check if two statements can be combined, whereas
before it would only combine two identical jumps.
I haven't been able to measure a significant slowdown, though I'm sure
it is at least a little bit slower.
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//1007103003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@44962 260f80e4-7a28-3924-810f-c04153c831b5
Revision 44880 added an assertion to accompany the internal error
message emitted if Parser._computeStringValue computes nonsensical
string start and end positions, so that those internal errors would be
noticed by the buildbots. It fixed most of the circumstances in which
the internal error might occur, but it missed a few: if the analyzer
encounters an unterminated string at the end of a line, or an
unterminated multiline string at the end of a file, or a string ending
with an invalid interpolation expression (e.g. "${var x}" or
"$class"), then a token might be generated which the parser thinks is
a complete string, but which consists solely of 1, 3, 4, or 5
consecutive quotes (and thus is an unterminated string), causing
Parser._computeStringValue to get confused and fire the assertion.
This CL addresses those problems by modifying
Parser._computeStringValue to handle those ill-formed tokens.
In a future CL I plan to modify the parser so that invalid
interpolation expressions like "${var x}" and "$class" are recovered
from more gracefully. But that is a low priority fix, since this CL
is sufficent to prevent the assertion from firing.
BUG=dartbug.com/23100
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1061883002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@44914 260f80e4-7a28-3924-810f-c04153c831b5
Previously, the logic for skipping the opening quote(s) (and optional
'r') of a string were erroneously being invoked after string
interpolations. As a result, a string like '${x}"y' was being
interpreted as '${x}y'. Usually, this had no visible user effect,
because analyzer's interpretation of strings is currently only used
for constant evaluation, and string interpolation is rare in constant
expressions. However, it was triggering an internal error in the case
where the interpolation is at the end of a multiline string, since it
caused analyzer to compute that the number of characters following the
interpolation was negative.
In addition to fixing the bug, I've modified the logic for logging the
internal error so that it also asserts; this allows the error to be
detected by unit tests. I've also fixed an off-by-one error in the
internal error logic which had prevented the bug from being noticed on
single-line strings.
BUG=dartbug.com/23046
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1056103002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@44880 260f80e4-7a28-3924-810f-c04153c831b5
karlklose@google.com