Add RESOLVED_UNIT_NO_CONSTANTS as a public result.
Document results that are computed with the task model.
We need this to be able to use onResultComputed() in Analysis Server and
know that we will get enough information.
R=brianwilkerson@google.com
BUG=
Review URL: https://codereview.chromium.org//1181603004.
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.
If a constant constructor does not contain an explicit call to
super(), and the base class lacks an explicit constructor, we need to
avoid marking the implicit base class constructor as a dependency,
since it is non-const. (Note: this shouldn't occur very often in
real-world usage since is a compile-time error, but we still need to
be able to analyze it without throwing an exception).
Fixes the following test when the new task model is switched on:
co19/Language/07_Classes/6_Constructors/3_Constant_Constructors_A03_t02
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//1168563004
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
Konstantin Shcheglov