I plan to use ClosureVariable for the variables assigned in try, so
the name will become incorrect. They are renamed to MutableVariable.
Use separate IR forms for declaration of MutableVariable (LetMutable)
and for assignment to mutable variables (SetMutableVariable). This
distinction doesn't do much in this change other than make the tree a
bit more well-formed, but I plan to make LetMutable take a list of
variables and values (e.g. all the variables mutated in a try).
R=asgerf@google.com, karlklose@google.com
BUG=
Review URL: https://codereview.chromium.org//898463002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@43396 260f80e4-7a28-3924-810f-c04153c831b5
Function definitions had a list of closure variables (which was always
empty in the JS backend). This list has no code generation semantics
because it is ignored by the Tree IR builder. Instead, when translating
to Tree IR, a reference to an unbound closure variable implicitly
'declares' it.
The closure variables were however used for the S-expression serialized
representation. They can be eliminated here as well by using the same
trick as the Tree IR builder.
R=asgerf@google.com
BUG=
Review URL: https://codereview.chromium.org//886053003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@43337 260f80e4-7a28-3924-810f-c04153c831b5
This reverts svn revision r43093, due to failures in dart2dart. It
clashes with the commit just before it which has changed the type of
FunctionDefinition parameters.
Also, continuation eta-reduction can destroy a dead parameter
reduction. In this case, it's not obvious which reduction we actually
want. So though the fixes are simple, I will back this change out and
reevaluate it.
R=asgerf@google.com
BUG=
Review URL: https://codereview.chromium.org//869223003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@43105 260f80e4-7a28-3924-810f-c04153c831b5
Continuation parameters that have no uses can be eliminated. This is
similar to the reduction for dead values except that that continuation
invocations need to be adjusted.
Performing a dead parameter reduction can create other dead parameter
redexes, dead value redexes, or continuation eta-redexes. Detection
of these redexes does not fit the existing model, where an entire
deleted subterm is visited after being eliminated from the whole term.
Instead, they are detected explicit as part of the reduction
implementation.
R=asgerf@google.com
BUG=
Review URL: https://codereview.chromium.org//864293004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@43093 260f80e4-7a28-3924-810f-c04153c831b5
LetCont can now bind multiple continuations in the same scope. As an
example, the 'then' and 'else' continuations of a branch are siblings
in the expression, and neither is in the scope of the other. None of
the LetCont-bound continuations are in scope for any of the
continuation bodies. Recursive continuations are still recursive
values, not recursive bindings, so there is no direct way to have
mutually recursive continuations. This matches the JavaScript
semantics.
R=asgerf@google.com, sigurdm@google.com, karlklose@google.com
BUG=
Review URL: https://codereview.chromium.org//848363002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@42945 260f80e4-7a28-3924-810f-c04153c831b5
Before: LetPrim and LetCont had "internal define" scoping, extending to
the end of the body they were in. After: they have "let" scoping, with a
body as a subexpression.
This change makes it easier to see scoping in the printed representation.
It also makes the printed representation more closely resemble the
internal representation. Finally, it is an advantage if writing the IR
by hand because expressions are balanced (Emacs, for example, can copy or
cut a balances S-expression).
Argument lists are changed to be always nested (enclosed by parentheses).
The basic rule of thumb is that the syntactic forms of the IR should all
have fixed arity (matching the internal representation), so that variable
arity parts such as arguments are represented as a single list.
BUG=
R=asgerf@google.com, floitsch@google.com, sigurdm@google.com
Review URL: https://codereview.chromium.org//833353002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@42630 260f80e4-7a28-3924-810f-c04153c831b5
This adds AccessSemantics support for constructions like:
class C {}
main() {
C();
}
Even though this will always lead to a runtime error, it only produces
a warning at compile time. Therefore AccessSemantics needs to
classify it correctly in order to allow the compilation back-end to
produce the correct runtime error.
R=scheglov@google.com
Review URL: https://codereview.chromium.org//816773002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@42480 260f80e4-7a28-3924-810f-c04153c831b5
Separate value parameters from the continuation for symmetry with
function invocations. Do not make closure variables optional. Do not
use '{' or '}', since it makes parsing more difficult and probably
screws up other tools that work with S-expressions.
Move closure variables after the parameters and just before the body,
since they are not part of the signature, do not appear at call sites,
and the implicit box creation happens at the beginning of the body
anyway.
R=asgerf@google.com, karlklose@google.com
BUG=
Review URL: https://codereview.chromium.org//810783002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@42395 260f80e4-7a28-3924-810f-c04153c831b5
Closure variables are now represented by a ClosureVariable object.
Previously they were identified by a LocalElement.
Parameters to a FunctionDefinition are now a mix of Parameter and
ClosureVariable. FunctionDefinitions also have a list of all the closure
variables they declare.
This change is a step toward supporting field initializers that modify or
capture function parameters.
BUG=
R=johnniwinther@google.com, sigurdm@google.com
Review URL: https://codereview.chromium.org//756383004
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@42164 260f80e4-7a28-3924-810f-c04153c831b5
An invocation of a factory constructor on class A does not necessarily
cause class A to be instantiated--it may redirect to a related or
unrelated class, or instantiate nothing at all.
We handle this by treating constructors similar to static function
calls--when a constructor invocation is found, the constructor element
is added to the queue; later, when the constructor element is
analyzed, we determine whether it instantiates the class or not based
on what kind of constructor it is.
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org//611153003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@40899 260f80e4-7a28-3924-810f-c04153c831b5
johnniwinther@google.com