- 19 Oct, 2012 1 commit
-
-
yangguo@chromium.org authored
BUG= Review URL: https://chromiumcodereview.appspot.com/11014017 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12768 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 28 Oct, 2011 1 commit
-
-
kmillikin@chromium.org authored
Also, handlify functions for loading with interceptors and callbacks. Remove some unneeded code. Rename Foreign::address() because it confusingly shadows HeapObject::address() which does something quite different. R=vegorov@chromium.org,ulan@chromium.org BUG= TEST= Review URL: http://codereview.chromium.org/8391045 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9834 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 Oct, 2011 1 commit
-
-
fschneider@chromium.org authored
Fix a use of the hole value and the undefined value before initialization when initializing V8. Before we just read a NULL value from them. Review URL: http://codereview.chromium.org/8130002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9557 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 Oct, 2011 1 commit
-
-
kmillikin@chromium.org authored
Instead of expecting Object** arrays at the outermost level, expect Handle<Object> arrays and reinterpret_cast them only just before invoking the generated code. R=rossberg@chromium.org,fschneider@chromium.org BUG= TEST= Review URL: http://codereview.chromium.org/8133020 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9537 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Sep, 2011 1 commit
-
-
mikhail.naganov@gmail.com authored
As pointed out in: http://codereview.chromium.org/7754007/#msg5 "SmartPointer should have been named SmartArrayPointer as it expects an input allocated using new[] and deallocates it using delete[]. Using it as a simple scoped pointer for a single object is incorrect." R=mnaganov@chromium.org Review URL: http://codereview.chromium.org/7860011 Patch from Thiago Farina <tfarina@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9215 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 19 May, 2011 1 commit
-
-
rossberg@chromium.org authored
Also fix grokdump, which was off by one after intro of JSProxy type. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7959 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Apr, 2011 1 commit
-
-
antonm@chromium.org authored
Review URL: http://codereview.chromium.org/6875003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7646 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Apr, 2011 1 commit
-
-
antonm@chromium.org authored
Instead discard unhandled exceptions thown while running message listeners. Review URL: http://codereview.chromium.org/6820003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7574 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Apr, 2011 1 commit
-
-
yurys@chromium.org authored
Stack overflow exceptions like other JavaScript exceptions should be reported to listeners added via V8::AddMessageListener Review URL: http://codereview.chromium.org/6816021 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7553 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Apr, 2011 1 commit
-
-
antonm@chromium.org authored
Correctly process failures which can be returned by Object::GetProperty when performing GetRealNamedProperty* queries. Callback properties can produce exceptions so we need to wrap access to them into exception checks. However, despite of many other methods with exception checks, property access doesn't mandatroy go via JavaScript and hence we need to inject code to propagate exception to public API TryCatch handlers. Review URL: http://codereview.chromium.org/6685087 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7548 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Mar, 2011 5 commits
-
-
vitalyr@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7271 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
vitalyr@chromium.org authored
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7269 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
vitalyr@chromium.org authored
Review URL: http://codereview.chromium.org/6685088 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7268 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
antonm@chromium.org authored
They apparently break Threading tests on at least Mac and Win64. TBR=vitalyr@chromium.org Review URL: http://codereview.chromium.org/6709028 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7262 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
antonm@chromium.org authored
Correctly process failures which can be returned by Object::GetProperty when performing GetRealNamedProperty* queries. Callback properties can produce exceptions so we need to wrap access to them into exception checks. However, despite of many other methods with exception checks, property access doesn't mandatroy go via JavaScript and hence we need to inject code to propagate exception to public API TryCatch handlers. Review URL: http://codereview.chromium.org/6397011 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7258 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Feb, 2011 1 commit
-
-
antonm@chromium.org authored
Plus use more robust path when formatting messages---work directly with fixed arrays. BUG=v8:1107 TEST=test/mjsunit/getter-in-prototype.js,test/mjsunit/regress/regress-1107.js Review URL: http://codereview.chromium.org/6451004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6689 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 Feb, 2011 1 commit
-
-
ager@chromium.org authored
an error message that needs to be generated and reported. This change hides all of the error information from JavaScript code so user callbacks cannot get hold of it. Review URL: http://codereview.chromium.org/6368051 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6574 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Oct, 2010 1 commit
-
-
erik.corry@gmail.com authored
Review URL: http://codereview.chromium.org/3970005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5698 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Jul, 2010 1 commit
-
-
yurys@chromium.org authored
Review URL: http://codereview.chromium.org/2961003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5043 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Mar, 2010 1 commit
-
-
kmillikin@chromium.org authored
Remove messages.h from v8.h and include it explicitly in only the few places it is needed. Many files relied on getting handles-inl.h implicitly from messages.h through v8.h, so include handles-inl.h explicitly in v8.h instead. Remove zone-inl.h from header files where it is not needed, can be replaced by a forward declaration, or can be replaced by zone.h (specifically, factory.h and heap.h). Include zone.h or zone-inl.h in header files where it was implicitly included via heap.h or factory.h. Prefer zone.h over zone-inl.h in header files where possible by including zone-inl.h in .cc files. Review URL: http://codereview.chromium.org/668248 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4058 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 19 Aug, 2009 1 commit
-
-
ager@chromium.org authored
The termination is achieved by throwing an exception that is uncatchable by JavaScript exception handlers. Review URL: http://codereview.chromium.org/174056 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2723 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 May, 2009 1 commit
-
-
mikhail.naganov@gmail.com authored
This issue was raised by Brett Wilson while reviewing my changelist for readability. Craig Silverstein (one of C++ SG maintainers) confirmed that we should declare one namespace per line. Our way of namespaces closing seems not violating style guides (there is no clear agreement on it), so I left it intact. Review URL: http://codereview.chromium.org/115756 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2038 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 23 Jan, 2009 1 commit
-
-
iposva@chromium.org authored
through the API. This allows us to verify state on entry through the API. In this change verification in the API entry is checking that the current thread holds the V8 lock when a HandleScope is instantiated if a v8::Locker has ever been used by the V8 instance. Review URL: http://codereview.chromium.org/18707 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@1140 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Nov, 2008 1 commit
-
-
ager@chromium.org authored
Assert in the Handle constructor that the object is not a failure. I have run our own tests in debug mode and the WebKit layout tests in debug mode and there are no regressions. Review URL: http://codereview.chromium.org/9114 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@691 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 23 Oct, 2008 1 commit
-
-
sgjesse@chromium.org authored
report the exception when they happen in the try block and not as previously when re-thrown after execution of the finally block. There is no longer any message generated by re-throw. Added test cases for various combinations of try/catch/finally with throw in different places. Added a regression directory to the messages tests which is processed by the test runner. Added regression tests for the specific bugs fixed. Runs all the test suites. BUG=73 BUG=75 Review URL: http://codereview.chromium.org/8050 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@565 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Oct, 2008 1 commit
-
-
feng@chromium.org authored
Here is a description of the background and design of split window in Chrome and V8: https://docs.google.com/a/google.com/Doc?id=chhjkpg_47fwddxbfr This change list splits the window object into two parts: 1) an inner window object used as the global object of contexts; 2) an outer window object exposed to JavaScript and accessible by the name 'window'. Firefox did it awhile ago, here are some discussions: https://wiki.mozilla.org/Gecko:SplitWindow. One additional benefit of splitting window in Chrome is that accessing global variables don't need security checks anymore, it can improve applications that use many global variables. V8 support of split window: There are a small number of changes on V8 api to support split window: Security context is removed from V8, so does related API functions; A global object can be detached from its context and reused by a new context; Access checks on an object template can be turned on/off by default; An object can turn on its access checks later; V8 has a new object type, ApiGlobalObject, which is the outer window object type. The existing JSGlobalObject becomes the inner window object type. Security checks are moved from JSGlobalObject to ApiGlobalObject. ApiGlobalObject is the one exposed to JavaScript, it is accessible through Context::Global(). ApiGlobalObject's prototype is set to JSGlobalObject so that property lookups are forwarded to JSGlobalObject. ApiGlobalObject forwards all other property access requests to JSGlobalObject, such as SetProperty, DeleteProperty, etc. Security token is moved to a global context, and ApiGlobalObject has a reference to its global context. JSGlobalObject has a reference to its global context as well. When accessing properties on a global object in JavaScript, the domain security check is performed by comparing the security token of the lexical context (Top::global_context()) to the token of global object's context. The check is only needed when the receiver is a window object, such as 'window.document'. Accessing global variables, such as 'var foo = 3; foo' does not need checks because the receiver is the inner window object. When an outer window is detached from its global context (when a frame navigates away from a page), it is completely detached from the inner window. A new context is created for the new page, and the outer global object is reused. At this point, the access check on the DOMWindow wrapper of the old context is turned on. The code in old context is still able to access DOMWindow properties, but it has to go through domain security checks. It is debatable on how to implement the outer window object. Currently each property access function has to check if the receiver is ApiGlobalObject type. This approach might be error-prone that one may forget to check the receiver when adding new functions. It is unlikely a performance issue because accessing global variables are more common than 'window.foo' style coding. I am still working on the ARM port, and I'd like to hear comments and suggestions on the best way to support it in V8. Review URL: http://codereview.chromium.org/7366 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@540 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Sep, 2008 1 commit
-
-
lrn@chromium.org authored
Slightly modified SmartPointer. Made String.ToWideCString return a SmartPointer instead of a plain pointer. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@271 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Sep, 2008 2 commits
-
-
christian.plesner.hansen@gmail.com authored
Added presubmit step to check copyright. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@242 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
christian.plesner.hansen@gmail.com authored
somewhat and folded stack traces into message. Use of this in the shell will follow in a separate changelist. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@235 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jul, 2008 1 commit
-
-
christian.plesner.hansen authored
git-svn-id: http://v8.googlecode.com/svn/trunk@2 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-