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
This fixes an assertion failure that occured after the optimizations in 0ef007d00b, when we tried to rewrite a field get for a .length expression, where we already had a more specific type and used that in a truncating divide.
R=floitsch@google.com
Review URL: https://codereview.chromium.org//1148093005
"x is Foo" will become getInterceptor(x).$isFoo
Testing against a type with type arguments is still a giveup().
This test always works, but is not very fast. For instance, testing
against an int should be "typeof x === 'number' && Math.floor(x) === x".
Following an offline discussion with Karl, the plan is to rewrite
'is'-checks to more fine-grained tests in a CPS optimization pass,
probably the type propagator.
Concretely, we plan to introduce IR nodes like TypeOfTest, FloorTest,
InstanceofTest, etc, which optimization phases can introduce under the
right circumstances. That way, the code generation phase remains simple.
BUG=
R=karlklose@google.com
Review URL: https://codereview.chromium.org//1144163004
This CL adds the implementation of all null-aware operators to dart2js. In
particular:
* a?.b: represented as 'isConditional' in the Send ast, and dispatched
separately by the semantic visitor using visitIfNotNull* methods.
* a ?? b: represented as an operator, and dispatched separately by the semantic
visitor using the `visitIfNull` method.
* a ??= b: represented as a compound operator.
All except 2 tests are passing with the SSA backend (those 2 tests fail for
unrelated reasons). I've marked the CPS ir tests as failing for now.
BUG=
R=johnniwinther@google.com, paulberry@google.com, sra@google.com
Review URL: https://codereview.chromium.org//1151163004
Stephan Herhut