- 31 Oct, 2011 1 commit
-
-
lrn@chromium.org authored
Previously we omitted all cases where the global eval property was shadowed, even if by a variable holding the same value. ES5 requires us to treat these as direct calls. We still throw if calling indirect eval with a detached global object. BUG=v8:994 TEST=mjsunit/eval.js Review URL: http://codereview.chromium.org/8343054 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9838 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 May, 2011 1 commit
-
-
ager@chromium.org authored
Make the call kind and call wrapper arguments explicit to force developers to make a choice. This would have avoided the bug in the first case. R=fschneider@chromium.org TEST=mjsunit/strict-mode-implicit-receiver.js Review URL: http://codereview.chromium.org/7086029 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8109 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 May, 2011 1 commit
-
-
ager@chromium.org authored
Only IA32 version for now. I'll start porting. Strict mode functions are to get 'undefined' as the receiver when called with an implicit receiver. Modes are bad! It forces us to have checks on all function calls. This change attempts to limit the cost by passing information about whether or not a call is with an implicit or explicit receiver in ecx as part of the calling convention. The cost is setting ecx on all calls and checking ecx on entry to strict mode functions. Implicit/explicit receiver state has to be maintained by ICs. Various stubs have to not clobber ecx or save and restore it. CallFunction stub needs to check if the receiver is implicit when it doesn't know from the context. Review URL: http://codereview.chromium.org/7039036 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8040 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-