You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This seems like a significant oversight, so in addition to reporting this, I'm kinda hoping for a sanity check and maybe some additional historical context from anybody who knows (was this definitely tested before?).
When haxe.CallStack.callStack() is called on the javascript target with ES5 code generation, running in Chrome (or presumably anywhere that V8 is used), any Method stack item that comes from a static or abstract function call will include the type information, but those that come from function calls on an instance of a type will not.
Running the same when ES6 code generation is enabled is even worse. No type names at all are included.
This is simple enough to fix in the standard library's javascript implementation of NativeStackTrace.prepareHxStackTrace for ES5 code. I have a commit prepared with a fix for that case (justin-espedal@243c4d9), but thought I'd withhold it pending discussion. For ES6 code I have no idea because site.getTypeName(), site.getFunctionName(), and site.getMethodName() all don't provide the needed information for static functions and abstracts.
The text was updated successfully, but these errors were encountered:
To maintain restrictions imposed on strict mode functions, frames that have a strict mode function and all frames below (its caller etc.) are not allow to access their receiver and function objects. For those frames, getFunction() and getThis() returns undefined.
site.getTypeName() only returns something useful for instance functions. To use haxe_NativeStackTrace.callStack as an example of a static/abstract function that we can't deal with:
Using the default string encoding of the callsite provides the info we need, but there's no other way to access the type name using the callsite API on ES6 in strict mode. I can only assume that this or function would have provided the information we need if they were available. In this case I guess we should fall back on parsing the default string output of the callstack.
This seems like a significant oversight, so in addition to reporting this, I'm kinda hoping for a sanity check and maybe some additional historical context from anybody who knows (was this definitely tested before?).
When
haxe.CallStack.callStack()
is called on the javascript target with ES5 code generation, running in Chrome (or presumably anywhere that V8 is used), anyMethod
stack item that comes from a static or abstract function call will include the type information, but those that come from function calls on an instance of a type will not.Running the same when ES6 code generation is enabled is even worse. No type names at all are included.
try.haxe program: https://try.haxe.org/#98c971A4
This is simple enough to fix in the standard library's javascript implementation of
NativeStackTrace.prepareHxStackTrace
for ES5 code. I have a commit prepared with a fix for that case (justin-espedal@243c4d9), but thought I'd withhold it pending discussion. For ES6 code I have no idea becausesite.getTypeName()
,site.getFunctionName()
, andsite.getMethodName()
all don't provide the needed information for static functions and abstracts.The text was updated successfully, but these errors were encountered: