I had a few thoughts on this but after evaluating it wouldn't work out...
If it were possible to modify java.lang.Throwable & StackTraceElement I had
thought to do some bit shifting to combine line & column numbers into a
negative number and place that as the line number value stored in the
LineNu
Note that nashorn always compiles to bytecode - no parallel side data
structure for JS stacks or "interpreter stack" here.
That said (if this can be done without hurting performance) we'd be
happy to accept contributions.
-Sundar
On 12/2/2016 4:34 PM, Art Fiedler wrote:
> Without knowing all th
Without knowing all the internals of nashorn. I don't know if an internal
calling tree exists or how complicated it would be to build, but it seems
the runtime could track function calls and maintain its own stack.
CallNode before code is generated has the token/linenumber where it came
from, stor
StackTraceElement being final is not the only issue here. How do to pass
around & populate column numbers for the script frames? That is the
main issue here..
-Sundar
On 12/2/2016 3:00 PM, Art Fiedler wrote:
> Yeah I almost mentioned that StackTraceElement doesn't provide a column
> number to po
Yeah I almost mentioned that StackTraceElement doesn't provide a column
number to populate but removed that comment, thinking "well,
StackTraceElement could just be extended for NashornStackTraceElement", but
now looking at it I notice it's final. ugh. But it doesn't technically mean
an array of St
Error has columnNumber property - but as you've noted it is not always
available :( If the error is thrown from script code anywhere via
ECMAScript throw statement, we do populate column number - because
nashorn could compile the code appropriately to put column number!
But, there are places in
Sorry, disregard the message below, it was meant for a different e-mail thread
:-)
> On 01 Dec 2016, at 13:53, Attila Szegedi wrote:
>
> Okay, I tracked this down to an incorrect optimization in code generator for
> when you use >>=0 to coerce to an uint32 :-(
>
> There is a special case for
Okay, I tracked this down to an incorrect optimization in code generator for
when you use >>=0 to coerce to an uint32 :-(
There is a special case for exactly this usage, where the right-hand-side
operand is a literal 0, so we avoid emitting a no-op “ICONST_0; IUSHR” bytecode
sequence. It unfor
We do not aim to provide complete compatibility with other JS
implementations on the non-standard properties such as "stack". stack
tries to mimic whatever is done for Java code (no column number for
eg.). But, as you've noted there are enough information on Error objects
via other properties l
