Since JsArrayAccess and JsNameRef have such similar semantics, I'd be a
little suspicious of any solution that doesn't handle the two similarly,
especially since both can be multi-line. (foo.\nbar is legal).
Handling the two differently means that it's more likely that were
hiding subtle bugs, since array access notation is less common than name
refs.
JsArrayAccess and JsNameRef are the only nodes that return qualified
references.
I think a reasonable solution would be too:
1. Have visit(JsInvocation) check if the invocation's qualifier is a
JsNameRef or JsArrayAccess. If so, it should only visit the qualifier's
qualifier, if it exists.
2. remove LocationVisitor.visit(JsNameRef).
3. Add LocationVisitor.endVisit(JsNameRef). It should be the same as
endVisit(JsArrayAccess) -- simply call record(x, ctx).
Doing so exposes a bug relating to the following code:
for (a.b in [0, 1, 2]) {
...
}
which is transformed to:
for ( location = '....', a.b in [0, 1, 2]) {
..
}
which is illegal.
We should change JsForIn to accept the iterExpr as an Lvalue, which
fixes this bug.
On 2010/01/20 18:57:36, Lex wrote:
Sam, for whatever reason, the stack emulator adds a line-number marker
for
foo[bar] but not for foo.bar. At a guess, this is because with
foo[bar], bar
can potentially be a complicated multi-line expression.
At any rate, it looks like a separate issue from issue 4512, though.
http://gwt-code-reviews.appspot.com/132815
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
