This CL makes analyzer consistent with the VM and the spec, by
producing a compile-time error for code such as:
class C {
final x = 1;
const C() : x = 2;
}
main() {
const C();
}
Note that Dart2js also produces an error in this circumstance, but its
error is too general (the error should only be produced if the const
constructor is invoked using "const"; if the const constructor is
invoked using "new", or is not invoked at all, it should only be a
warning). See #23618.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1175073002.
It is a compile-time error for a constant value to depend on a
non-constant value (or a non-constant constructor), however the
analyzer still needs to be able to handle it.
This CL adjusts the ConstantEvaluationEngine so that it consistently
reports all the dependencies of a given constant (whether those
dependencies are constant are not), but which is tolerant of being
asked to compute a constant value of a non-constant.
Fixes test failures with the new task model enabled. No behavioral
change with the new task model disabled.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1167413005.
If 'p' is an import prefix, then 'p = ...' is treated as synonymous
with 'this.p = ...', and 'p()' is treated as synonymous with
'this.p()'. In all other circumstances where 'p' is not followed by
'.', the spec calls for a compile time error.
Previous to this CL, 'p' not followed by '.' was being treated as
synonymous with 'this.p' under all circumstances. This CL brings
analyzer in line with the spec, and updates the tests in
tests/language accordingly.
The VM and Dart2js currently fail to implement the compile-time error
properly. See issues #23611 and #23612.
Fixes issue #23461.
R=scheglov@google.com
Review URL: https://codereview.chromium.org//1173523002.
This is a re-fix of dartbug.com/21912, which I previously fixed
incorrectly. Previously, our approach to avoiding infinite loops when
comparing types was to maintain a set of typedefs being expanded on
the stack, and prune the comparison whenever an attempt was made to
expand a typedef that was already being expanded. However, this was
too strict, since there are legal (non-circular) types which invole
expanding a given typedef in reentrant fashion; we can't prune these
types without producing incorrect semantics. An example (from the bug
report) is the type of f in the code below:
typedef T Function2<S, T>(S z);
Function2<Function2<A, B>, Function2<B, A>> f;
The solution is to maintain the list of typedefs being expanded inside
each FunctionTypeImpl object (and InterfaceTypeImpl object) rather
than on the stack during the comparison; this allows us to distinguish
the situations where we need to prune (those having to do exclusively
with expansion of a typedef) from the situations where we shouldn't
prune (those having to do with substitution of a type parameter).
A beneficial side effect of this change is that code that interacts
with types no longer needs to worry about typedef circularities, since
the circularities will automatically be pruned while exploring the
type definitions. This simplifies the implementation of
isAssignableTo, isSubtypeOf, operator==, and hashCode. (Note,
however, that code still needs to cope with circularities in the
inheritance hierarchy).
BUG=dartbug.com/21912
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1143003007
This fixes a dependency problem in ComputeConstantDependenciesTask.
Prevously it used element.library.source to get access to the library
source, but this created an implicit dependency on LIBRARY_ELEMENT1
(since element.library is null if the library element hasn't been
built yet). There was no way to make that dependency explicit since
previous to this change, the CompilationUnitElement did not store
enough information to determine what library it was part of until
after the library element had been created.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1125123006
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45674 260f80e4-7a28-3924-810f-c04153c831b5
This paves the way for constant evaluation to be integrated into the
new task model, since the new tasks for constants will use elements as
their targets.
Since the element model makes a distinction between constructor
members and constructor elements, we have to be careful to be
consistent about what kinds of elements are stored in the dependency
graph. We always store constructor elements in the dependency graph.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1129143003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45611 260f80e4-7a28-3924-810f-c04153c831b5
Instead of treating them as separate nodes in the dependency graph,
evaluate them directly in the ConstantVisitor at the time they are
needed. This makes the dependency graph more uniform, since
everything in it is now associated with an element. This should make
it easier to adapt constant evaluation to the new task model.
In order to avoid introducing regressions with this change, I had to
implement proper reporting of cycles in compile-time constants.
(Previously, this was unimplemented but worked correctly in most cases
by luck.)
Note: technically this constitutes a breaking API change, since it
removes the field constantHandle and the getter evaluationResult from
the InstanceCreationExpression class. I believe these members are not
used outside of analyzer, so I'm leaving the analyzer version number
as is.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1124733008
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45541 260f80e4-7a28-3924-810f-c04153c831b5
Previously, we used static resolution to determine whether
String.length was being referred to, causing incorrect results in the
presence of bad type annotations. Also, we were missing a null check,
causing constant evaluation to crash if an attempt was made to take
the length of a constant that couldn't be evaluated.
BUG=dartbug.com/23383
R=scheglov@google.com
Review URL: https://codereview.chromium.org//1124433007
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45524 260f80e4-7a28-3924-810f-c04153c831b5
Since r44861, ElementBuilder is responsible for creating the
ConstantInstanceCreationHandle objects associated with
InstanceCreationExpressions. Since InstanceCreationExpressions may
appear inside annotations, we must make sure the ElementBuilder visits
all annotations. Previous to this change, it didn't visit function
annotations.
BUG=dartbug.com/23354
R=scheglov@google.com
Review URL: https://codereview.chromium.org//1125613003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@45489 260f80e4-7a28-3924-810f-c04153c831b5
Paul Berry