Improve position accuracy in Rhino parser.
These changes continue to improve position accuracy in the
older Node parse tree nodes, primarily for expressions. The
changes do the following:
* Set the line number of infix operations to the line where
the operator appears, not where the overall expression begins.
* Fix memberExprTail to mark function calls on the line where
the left paren enclosing the expressions appears, rather than
where the name appears.
* Ensure that position information is gathered for
objectLiteral property lists, and that the key and value both
get accurate line information.
* Mark all string literal nodes with the line where the string appears.
These changes should help anyone reporting error messages
based on the lineno field of a Node or doing any other
position-sensitive operations with nodes.
Background:
Before the 11/2008 submission of the new AstNode parse tree,
line numbers were recorded only for statements, not for
expressions. Steve Yegge's new changes added line number
information for many nodes, and also added more precise
information to the new ASTnodes based on absolute offset in the
text stream.
One drawback of the line number information for plain Nodes is
that it follows the AstNode's convention of having the
position mark the start of the expression. This matches the
behavior of positions in AstNode where intermediate points of
interest (the operator in an infix binary expression, or the
parentheses in a function call) are also remembered as offsets from
the beginning of the overall expression.
However, this causes problems for anyone using the older Node parse
tree because naive code generating errors or source mappings
only have access to the stored line number, and might point at code
multiple lines away from the actual source of the problem. An
error in a multi-line condition would point to the beginning
of the condition, or a caller trying to show the location of a
function call would point at the beginning of the name
representing the function, even if that name were a few lines
away. We see a bunch of these multi-line expressions in our
own source code, and an unchanged Rhino would direct programmers
at the wrong line for the error.
Following the convention that the line number always
represents the line of the most representative "token" not
only helps understanding, but gives better information. We
can still find the entire range of the expression by looking
at the lines of all sub-expressions, and we can find the line
and column of an arbitrary interesting Node quickly by
assuming the line number is correct, then looking at the file
at the absolute position given by the AstNode, and searching
backwards in the text for a carriage return.
I searched a bit in the Rhino sources for clients of getLineno()
who might be affected by these changes, and didn't see any obvious
cases where these changes might cause problems.
git-svn-id: svn://10.0.0.236/trunk@257776 18797224-902f-48f8-a5cc-f745e15eee43
Previously Object.getOwnPropertyDescriptor(Math, "PI") returned undefined.
This patch makes the members of builtin objects have descriptors with
Writable=true, Enumerable=false, Configurable=true for function properties, and
Writable=false, Enumerable=false, Configurable=false for non-function
properties
See https://bugzilla.mozilla.org/show_bug.cgi?id=489329
git-svn-id: svn://10.0.0.236/trunk@257741 18797224-902f-48f8-a5cc-f745e15eee43
Allows getting and setting attributes on index properties when the array is in
dense mode.
git-svn-id: svn://10.0.0.236/trunk@257702 18797224-902f-48f8-a5cc-f745e15eee43
Fixed incorrect node positions for labeled statements and finally blocks.
Labels: when parsing a labeled loop, we set the loop's parent to the
LabeledStatement before parsing the loop's children, which messes up
their offsets. Worked around the problem by temporarily adjusting the
loop's position while parsing the children.
Try statements had two bugs:
- the parser was setting the 'finally' keyword's position incorrectly
(wasn't setting it relative to parent)
- the toSource() method threw a NullPointerException for a
try/finally block with no catch clauses.
Also fixed AstNode.setParent() to un-relativize the node's position if
the node already had a parent. This doesn't happen in Rhino's parser, but
if users are doing tree rewrites they could have run into bad offsets.
Patch from Steve Yegge
git-svn-id: svn://10.0.0.236/trunk@257294 18797224-902f-48f8-a5cc-f745e15eee43
