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
In order to unit test that this change doesn't regress the handling of
"const Symbol(...)", it was necessary to expand TestTypeProvider's
Symbol class to include the Symbol constructor.
Note: with this fix, analyzer detected a previously unknown flaw in
tests/language/switch_case_test.dart: class D didn't implement a
getter for x. Test updated accordingly.
This change breaks test lib/_internal/compiler/samples/jsonify/jsonify
by changing analyzer's handling of bool.fromEnvironment(). I plan to
address this in a future changelist.
BUG=dartbug.com/17209
R=brianwilkerson@google.com, floitsch@google.com
Review URL: https://codereview.chromium.org//261403004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@35853 260f80e4-7a28-3924-810f-c04153c831b5
Consider the classes:
class A<T> {}
class B<T> extends A<T>
class C<T> extends A<T>
class D {}
class E {}
When computing the least upper bound of B<D> and C<E>, we were making
two mistakes:
1. When computing superclasses we were using
ClassElement.getSupertype() (which doesn't substitute type arguments),
so B<D> and C<E> were considered to derive from a common type A<T>
rather than distinct types A<D> and A<E>. A similar problem existed
for interfaces.
2. When intersecting superinterface sets, we were recursively taking
the least upper bound of type arguments, so A<D> and A<E> were
coalesced into A<Object>. The spec and VM consider A<D> and A<E> to
be unrelated types for the purpose of least upper bound computation,
so the least upper bound should simply be Object.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//234213002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@34952 260f80e4-7a28-3924-810f-c04153c831b5
sigurdm@google.com