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
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, two analyzer error messages (one recently introduced by
me, and one that has been around for a while) failed to provide enough
arguments to populate the error message template, resulting in
user-visible strings like "{0}" showing up in error messages.
This CL fixes the problem, and safeguards against it happening again
in the future by adding assertions to verify, at the time the error
message is formatted, that enough arguments were passed.
R=scheglov@google.com
Review URL: https://codereview.chromium.org//1059263004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@44911 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
The resolver now copies the resolved AST's for the initializers of
constant variable declarations into the element model. This is a
necessary prerequisite for moving constant evaluation into the new
task model, since in the new task model, the original AST nodes won't
be available at constant evaluation time.
Also, the resolver is now responsible for copying the resolved
initializer lists for constant constructors into the element model.
This was previously done at constant evaluation time, but once again
in the new task model the original AST nodes won't be available at
constant evaluation time.
Since not all constants are guaranteed to have been evaluated at the time
that the resolver makes these copies, we can no longer store the
evaluationResult for an InstanceCreationExpression in its AST node
(it's no longer guaranteed to get copied safely). So instead, we
store the evaluationResult in an intermediate object called
ConstantInstanceCreationHandle; that way the copied AST node will
point to the same ConstantInstanceCreationHandle as the original AST
node, so once the constant is evaluated, the resulting value will be
accessible from both AST nodes.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1050203002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@44861 260f80e4-7a28-3924-810f-c04153c831b5
paulberry@google.com