Class names are no longer private. optimizers.dart whitelists the class
that needs to be exposed, so the privacy makes little difference.
Methods on AbstractValue that require access to the type system or
other "external thing" have been moved to ConstantPropagationLattice.
It should help readability and avoid parameter inflation when more
external things are suddenly needed to answer a query.
The UnitTypeSystem has been removed and TypeSystem has been merged
into TypeMaskSystem. The generic variable T has been removed as well.
BUG=
R=kmillikin@google.com
Review URL: https://codereview.chromium.org//1173563002.
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
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
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
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
Stephan Herhut