This re-applies commit 43626, which was reverted in 43628.
What happened: I accidentally tested r43626 against a work-in-progress
build of the Java-based dartanalyzer that contained r43655, so I
failed to update the status files properly. This resulted in a build
failure, which was addressed by reverting r43626. Now that r43655 has
landed, the build failure should not occur.
R=hausner@google.com
Review URL: https://codereview.chromium.org//910243002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@43666 260f80e4-7a28-3924-810f-c04153c831b5
Backport of r43613, r43537, r43446, r43427, r43424, r43418, r43403,
r43361 to the Java-based analyzer. The backport is partial in that
the TypeProvider was not modified to include Future and Stream types
(this would have required substantial additional effort), and
consequently not all static warnings are correctly produced. However,
all NonErrorResolverTest cases were successfully backported and pass,
meaning that the Java-based analyzer shouldn't produce false positive
warnings for async/await code anymore.
BUG=dartbug.com/22252
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//913623002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@43655 260f80e4-7a28-3924-810f-c04153c831b5
This changes analyzer to match the spec (and the VM behavior) with
regard to which base class constructors are forwarded through mixin
applications: only those constructors that take zero optional
parameters are forwarded. In addition, the tests in tests/language/
are updated to match analyzer and the VM.
There is one small difference between analyzer and the VM behavior:
the spec says that if no constructors are forwarded at all, then the
mixin application will automatically acquire an implicit default
constructor. The VM behavior is to issue an error in this
circumstance. After consulting with Gilad, it seems like the VM
behavior is more consistent with the intent, so I've chosen to make
analyzer and the tests match the VM behavior, in the hopes that the
spec can be changed accordingly.
Should we change our minds in the future and decide that we want to
keep the spec as is, the tests and analyzer behavior can easily be
changed.
BUG=dartbug.com/19576
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//707073002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@41645 260f80e4-7a28-3924-810f-c04153c831b5
This CL changes EvaluationResultImpl from abstract to concrete, and
eliminates its derived classes, ValidResult and ErrorResult. This
eliminates the dichotomy between "compile time constant that computed
successfully" and "compile time constant that failed to compute
because of errors", so that we can keep track of errors encountered
during successful evaluation of a constant (this is necessary to
support checked mode compile-time errors). It also avoids the need to
do double dispatch between the two derived classes in order to
evaluate constants involving binary operators.
We now keep track of constant evaluation errors my accumulating them
into a list (which is passed as a constructor argument into
ConstantVisitor). This allows ConstantVisitor to represent its
intermediate values using DartObjectImpl directly, and fixes some
corner cases where we were dropping or duplicating constant evaluation
errors.
As a result of fixing the corner cases, issue 21177 is exposed.
(Previously the test "compile_time_constant10_test/none" failed to
show the bug due to the error being dropped).
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//613303003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@40856 260f80e4-7a28-3924-810f-c04153c831b5
This enables the Java-based command-line analyzer to accept the
"--enable_type_checks" flag so that it can be told whether to report
type checking errors during constant evaluation. Also it fixes the
tests language/compile_time_constant_checked2_test and
language/compile_time_constant_checked3_test in unchecked mode, by
causing CONST_FIELD_INITIALIZER_NOT_ASSIGNABLE to be escalated to an
error only in checked mode.
Note: in order to test this properly, I had to remove a hack from
test_runner.dart which caused it to effectively ignore the "checked
mode compile-time error" test annotation when testing analyzer. With
this hack removed, several new lines needed to be added to the .status
files.
BUG=dartbug.com/16391
R=jwren@google.com, kustermann@google.com
Review URL: https://codereview.chromium.org//610863004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@40780 260f80e4-7a28-3924-810f-c04153c831b5
If a final instance variable is initialized at the point of declaration, it
is a runtime error if it is initialized again in a constructor’s initializer
list or by an initializing formal.
If any instance field is initialized more than once in the initializer list of
a constructor, or by an initializing formal parameter, it is a compile time
error.
Adding a new test to cover the expected runtime error.
Fixes issue 13335.
R=regis@google.com
Review URL: https://codereview.chromium.org//505033002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@39562 260f80e4-7a28-3924-810f-c04153c831b5
Previously, we evaluated them in ConstantVisitor; as a result we
couldn't take advantage of the ConstantValueComputer's depedendency
graph, so we couldn't detect cycles involving constant constructor
declarations. This will become important soon, when we expand our
constant evaluation logic to traverse constructor field initializers.
With this change, ConstantValueComputer stores the computed value of
each constant instance creation expression in the AST (similar to how
it stores the computed value of each constant variable in the element
model), and ConstantVisitor simply looks up the already-computed
value.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//270813004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@35969 260f80e4-7a28-3924-810f-c04153c831b5
paulberry@google.com