We now optimize type casts that always fail or always pass.
Type propagation has been refactored a bit to make this work.
A new IR node Unreachable has been added. This is an node that is known
to be unreachable and is ultimately compiled to an empty statement.
BUG=
R=karlklose@google.com
Review URL: https://codereview.chromium.org//1153603006
- Complete revamp of isolate-specific flags.
- Associate flags with the isolate on creation.
- Dart_CreateIsolate and associate callback do take an
extra flags argument.
- Make sure to clear IC data array when clearing code.
BUG=23578
Review URL: https://codereview.chromium.org//1162033005
Re-generate the indices after deserialization.
This is a more compact representation, and also fixes the issue with identity hash codes not being portable between isolates.
BUG=21675
R=asiva@google.com
Review URL: https://codereview.chromium.org//1151013005
If the receiver is null, the arguments are not evaluated.
Example:
Dart:
var x = null;
var y = bar();
x.foo(y);
JS before:
null.foo$1(bar());
JS after:
var y = bar();
null.foo$1(y);
If the receiver is known not be null, we still propagate into the
arguments, and "pure" expressions can always propagate even if the
receiver might be null.
InvokeMethod now has a field isReceiverNotNull, which carries a bit of
static type information. Another field like this is InvokeStatic.isPure.
I intentionally chose to pass along the *least* amount of information
that is sufficient for what we need in the tree optimizations.
That CPS type propagation was not very good at proving when things are
not null, so a couple of things missing from it have been filled in.
BUG=
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//1159643005
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
Removing dart2dart stuff is the most radical change, but there's also
a bunch of general clean up, some of it somewhat unrelated, but long
overdue.
I've focused on making the IR easier to read end-to-end.
For instance, I've stripped out a complicated assertion on InvokeMethod,
because it is distracting and hasn't paid off. AFAIK it never caught a
single bug, but a few times it has spuriously failed and needed
patching.
Some notable changes in the IR:
- Removed FieldDefinition, ConstructorDefinition, Initializers.
- Removed RootNode. There was only one subclass left.
- Removed Body. Has been inlined into FunctionDefinition.
- MutableVariable can no longer be a function parameter.
- Removed default parameter values and local constants from the IR.
I decided to keep nested functions for the time being because there is
a slight chance they might come in handy for async/await.
I'm not sure yet. We can strip them out later if they are not needed.
I've also left the subclassing JsIrBuilder <: IrBuilder for now,
even though the classes could be merged. Same with the visitor.
BUG=
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//1155463005
It's still not a good solution for detecting an Iterable with an efficient
length. It's not inherited by, e.g., a DelegatingIterable wrapper or similar
generic Iterable transformers.
Keep this as an internal optimization for quickly detecting the most common
efficient-length Iterable classes (List, Set, Queue, Map.keys/values), but
don't make it public.
A *real* solution would be adding a hasEfficientLength getter to Iterable, or
adding an efficientLength getter that may return null if it's not efficient.
This would something that a wrapper can attach to.
R=sgjesse@google.com
Review URL: https://codereview.chromium.org//1154263003
Previously there was a problem with type variables referenced inside
a closure inside a field initializer, like so:
class Foo<T> {
var field = () => T;
}
The type variable cannot be accessed on 'this' because the closure is
created before 'this'. It also cannot be accessed as a parameter.
It is now properly treated as an unboxed free variable, and at
closure creation the value is taken from the constructor parameter
holding the type variable.
As with everything else during constructor build-up, the type variables
are now held in the IR builder's environment. It has proven to be a
robust way of doing things so far.
This simplifies the IR builder's role in this. The builder will not
detect how a type variable should be accessed (i.e. "if inside
a closure inside a field..."). If the type variable is in the
environment that's the one it will use, otherwise it defaults to
extract it from the receiver object.
Also, the closure conversion phase now detects type variables
mentioned in "on T catch()" clauses.
BUG=
R=karlklose@google.com
Review URL: https://codereview.chromium.org//1158693003
