NPN_Construct allows a NPObject to be called as a construct. For example, the
test case
var s = new app.Packages.java.lang.Integer(5);
app.Packages.java.lang.Integer is a NPObject, and it implements NPN_Construct.
This fix allows a JSObject created by an API function be called as a construct
if it can be called
as a function. This is done by generating the same code for
var s = new app.Packages.java.lang.Integer(5); as
var s = app.Packages.java.lang.Integer(5);
and the caller handles both case correctly. A more sophiscated fix is to one
extra JSConstructCall
frame and allow CallAsConstructor in Builtin::HandleApiCallAsFunction.
This change itself shouldn't affect the semantic of normal case such as:
var a = {};
var s = new a();
A TypeError exception will be thrown in CALL_NON_FUNCTION (runtime.js).
Another part of fix is in the binding code, V8NPObject, which makes
NPN_InvokeDefault or NPN_Construct
call depending on which function is available.
Review URL: http://codereview.chromium.org/100243
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1837 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
numerical order independently of the representation of the object.
Exchanged the order of enumeration of integer and string keys so
integer keys are first instead of string keys to better match
WebKit/JSC behavior.
Added test cases that document our enumeration order choice.
Review URL: http://codereview.chromium.org/75035
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1722 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Fix exception propagation problem where undefined was returned instead
of an empty handle in case of an exception. This problem can break
C++ programs that are not interested in catching exceptions and just
want to propagate them out by testing for empty handles.
The issue is that exceptions are not rescheduled if they are
externally caught. Externally caught exceptions have to be
rescheduled if there is a JavaScript frame on the way to the C++ frame
that holds the external handler.
A couple of tests will fail on the ARM simulator because the simulator
has separate stacks for C++ and JavaScript. I have marked the tests
as failing only on the simulator.
Review URL: http://codereview.chromium.org/56105
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1657 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- String traversal test data (now in a zone)
- Debug message thread (now joined on exit)
- Threading test threads (now joined on exit)
- Changed message tests framework to cope with valgrind
Also, fixed a bug where we'd try to delete stack-allocated objects
when tearing down v8. Good times.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1622 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Cleaned up the handling of strings moving, so strings moved by GC and strings changing representation are handled equivalently.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1562 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Exclude the tests from the threaded tests because I don't want to
disable those on ARM.
The issue is that the simulator keeps the C++ and the JavaScript stack
separated. This is not a problem on the real hardware and the tests
pass on our ARM box.
Review URL: http://codereview.chromium.org/42069
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1492 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
of an empty handle in case of an exception. This problem can break
C++ programs that are not interested in catching exceptions and just
want to propagate them out by testing for empty handles.
The issue is that exceptions are not rescheduled if they are
externally caught. Externally caught exceptions have to be
rescheduled if there is a JavaScript frame on the way to the C++ frame
that holds the external handler.
Review URL: http://codereview.chromium.org/43070
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1487 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The problem is that Disable/EnableAccessCheck on an object may chnage its constructor's behavior
if object's map is the same as constructor's initial map. By copying maps, the constructor's
initial map is not changed.
Review URL: http://codereview.chromium.org/18067
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1087 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
calling a stub. The map to check against is unknown when generating
the code, so we patch the map check in the IC initialization code.
Loop nesting is currently not tracked on ARM. I'll file feature
request bug reports for implementing this on ARM and add the number to
the TODOs before I commit.
Review URL: http://codereview.chromium.org/16409
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1015 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
