to having value undefined
As per 8.6.1 Table 3.
Patch from Raphael Speyer.
git-svn-id: svn://10.0.0.236/trunk@257969 18797224-902f-48f8-a5cc-f745e15eee43
Make defineProperty throw a TypeError when attributes is both data and accessor descriptor. As per 8.10.5 step 9 of the spec.
Patch from Raphel Speyer.
git-svn-id: svn://10.0.0.236/trunk@257920 18797224-902f-48f8-a5cc-f745e15eee43
reduce and reduceRight throw a TypeError when array empty and no initVal
As per 15.4.4.21 step 5, and 15.4.4.22 step 5 of the spec.
Patch from Raphael Speyer.
git-svn-id: svn://10.0.0.236/trunk@257918 18797224-902f-48f8-a5cc-f745e15eee43
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
