Remove usage of to-be-deprecated APIs from v8 core

Remove usage of to-be-deprecated APIs from v8 core

Also turn on the macro to disable to-be-deprecated APIs for core

BUG=v8:4134
R=vogelheim@chromium.org
LOG=n

Committed: https://crrev.com/696184a0477054897aec76946f3715682451ac5c
Cr-Commit-Position: refs/heads/master@{#28783}

[vogelheim, 2015-06-03 08:01:46]

https://codereview.chromium.org/1162363005/diff/1/tools/gyp/v8.gyp
File tools/gyp/v8.gyp (right):

https://codereview.chromium.org/1162363005/diff/1/tools/gyp/v8.gyp#newcode369
tools/gyp/v8.gyp:369: 'V8_IMMINENT_DEPRECATION_WARNINGS',
Some compilers still have issues with this, it seems.

[jochen (gone - plz use gerrit), 2015-06-03 08:03:52]

ptal

[jochen (gone - plz use gerrit), 2015-06-03 08:08:19]

On 2015/06/03 at 08:03:52, jochen wrote:
> ptal

meh, gcc still doesn't like it :-/

[vogelheim, 2015-06-03 08:23:13]

lgtm

Some nitpicks. But if the compilers are happy, I'm too. :)

https://codereview.chromium.org/1162363005/diff/20001/src/accessors.cc
File src/accessors.cc (right):

https://codereview.chromium.org/1162363005/diff/20001/src/accessors.cc#newcod...
src/accessors.cc:1416: }
I don't think I understand the logic here:

Previously, if info.Data() didn't contain a valid slot number, if would run into
the DCHECK in FixedArray::get. I presume that in release builds, it would just
wildly access memory. Apparently, this code assumed that surely the slot number
would be valid.

This now checks for one specific error condition, namely no slot number being
given at all, but all other error conditions are still unchecked. Why? If we
assume it's the caller responsibility to provide valid data, then why handle
this particular situation?

https://codereview.chromium.org/1162363005/diff/20001/src/api.cc
File src/api.cc (right):

https://codereview.chromium.org/1162363005/diff/20001/src/api.cc#newcode325
src/api.cc:325: .ToLocal(&resource_name)) {
How could this NewFromUtf8 call fail?

https://codereview.chromium.org/1162363005/diff/20001/src/extensions/gc-exten...
File src/extensions/gc-extension.cc (right):

https://codereview.chromium.org/1162363005/diff/20001/src/extensions/gc-exten...
src/extensions/gc-extension.cc:23:
->BooleanValue(args.GetIsolate()->GetCurrentContext())
style nitpick: Why newline + 8 indent?

[jochen (gone - plz use gerrit), 2015-06-03 09:43:57]

https://codereview.chromium.org/1162363005/diff/20001/src/accessors.cc
File src/accessors.cc (right):

https://codereview.chromium.org/1162363005/diff/20001/src/accessors.cc#newcod...
src/accessors.cc:1416: }
On 2015/06/03 at 08:23:13, vogelheim wrote:
> I don't think I understand the logic here:
> 
> Previously, if info.Data() didn't contain a valid slot number, if would run
into the DCHECK in FixedArray::get. I presume that in release builds, it would
just wildly access memory. Apparently, this code assumed that surely the slot
number would be valid.
> 
> This now checks for one specific error condition, namely no slot number being
given at all, but all other error conditions are still unchecked. Why? If we
assume it's the caller responsibility to provide valid data, then why handle
this particular situation?

fair enough

i'm now checking for other invalid values as well

https://codereview.chromium.org/1162363005/diff/20001/src/api.cc
File src/api.cc (right):

https://codereview.chromium.org/1162363005/diff/20001/src/api.cc#newcode325
src/api.cc:325: .ToLocal(&resource_name)) {
On 2015/06/03 at 08:23:13, vogelheim wrote:
> How could this NewFromUtf8 call fail?

it can't. Made it ToLocalChecked()

https://codereview.chromium.org/1162363005/diff/20001/src/extensions/gc-exten...
File src/extensions/gc-extension.cc (right):

https://codereview.chromium.org/1162363005/diff/20001/src/extensions/gc-exten...
src/extensions/gc-extension.cc:23:
->BooleanValue(args.GetIsolate()->GetCurrentContext())
On 2015/06/03 at 08:23:13, vogelheim wrote:
> style nitpick: Why newline + 8 indent?

clang-format

[jochen (gone - plz use gerrit), 2015-06-03 10:25:18]

The CQ bit was checked by jochen@chromium.org

[jochen (gone - plz use gerrit), 2015-06-03 10:25:18]

The patchset sent to the CQ was uploaded after l-g-t-m from
vogelheim@chromium.org
Link to the patchset: https://codereview.chromium.org/1162363005/#ps40001
(title: "updates")

[commit-bot: I haz the power, 2015-06-03 10:25:30]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1162363005/40001

[commit-bot: I haz the power, 2015-06-03 10:27:56]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-06-03 10:28:05]

Patchset 3 (id:??) landed as
https://crrev.com/696184a0477054897aec76946f3715682451ac5c
Cr-Commit-Position: refs/heads/master@{#28783}