New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deps: update V8 to 5.7 #11752

Merged
merged 10 commits into from Mar 25, 2017

Conversation

Projects
None yet
@targos
Member

targos commented Mar 8, 2017

Marking in-progress because Chrome 57 is still in beta.
I'm also waiting on https://codereview.chromium.org/2736873005/ to drop the gyp patches.

Notable changes (source):

  • faster promises and async functions
  • faster spread operator, destructuring and generators
  • faster RegExps
  • new String methods: padStart and padEnd
  • new Intl method: Intl.DateTimeFormat.prototype.formatToParts
  • WebAssembly enabled by default
  • PromiseHook C++ API (cc @trevnorris)
Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines

/cc @nodejs/v8

@targos

This comment has been minimized.

Show comment
Hide comment
@targos

targos Mar 8, 2017

Member

This is actually blocked on three issues that I forgot about:

Member

targos commented Mar 8, 2017

This is actually blocked on three issues that I forgot about:

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Mar 9, 2017

Member

@targos ... just an update, I'll be cutting the 8.x branch next monday with an eye towards cutting the first release candidate on April 4th.

Member

jasnell commented Mar 9, 2017

@targos ... just an update, I'll be cutting the 8.x branch next monday with an eye towards cutting the first release candidate on April 4th.

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Mar 9, 2017

Member

first release candidate on April 4th

You mean beta, right? Like, is there actually a chance that what you cut on April 4 will basically end up being the release?

Member

Trott commented Mar 9, 2017

first release candidate on April 4th

You mean beta, right? Like, is there actually a chance that what you cut on April 4 will basically end up being the release?

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Mar 9, 2017

Member

First beta will be next week after I cut the branch. The goal is to start stabilizing everything as quickly as possible with no more majors landing without CTC review after April 4th. Release candidate may be too strong but it should be more stable than beta. I'm going to be limiting minors also unless they've been in a 7.x release.

Member

jasnell commented Mar 9, 2017

First beta will be next week after I cut the branch. The goal is to start stabilizing everything as quickly as possible with no more majors landing without CTC review after April 4th. Release candidate may be too strong but it should be more stable than beta. I'm going to be limiting minors also unless they've been in a 7.x release.

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Mar 9, 2017

Member

I'd say a little pragmatism is needed when it comes to V8 because we'll be stuck with that particular version for a long time. A glitch or two in the initial 8.0.0. release is perfectly okay if it means easier longer-term maintenance.

Also, WASM seems like a relevant enough addition for a LTS release.

Also also, I don't fancy fielding bug reports about the spread operator slowing down someone's script for the next couple of years.

Member

bnoordhuis commented Mar 9, 2017

I'd say a little pragmatism is needed when it comes to V8 because we'll be stuck with that particular version for a long time. A glitch or two in the initial 8.0.0. release is perfectly okay if it means easier longer-term maintenance.

Also, WASM seems like a relevant enough addition for a LTS release.

Also also, I don't fancy fielding bug reports about the spread operator slowing down someone's script for the next couple of years.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Mar 9, 2017

Member

Oh indeed. The discussion on the ctc call today was that we would definitely land with 5.7 and hopefully with 5.8.

Member

jasnell commented Mar 9, 2017

Oh indeed. The discussion on the ctc call today was that we would definitely land with 5.7 and hopefully with 5.8.

@bricss

This comment has been minimized.

Show comment
Hide comment
@bricss

bricss Mar 9, 2017

It would be awesome if it would be V8 5.8, the whole world count on this. 🤓

bricss commented Mar 9, 2017

It would be awesome if it would be V8 5.8, the whole world count on this. 🤓

@targos

This comment has been minimized.

Show comment
Hide comment
@targos

targos Mar 9, 2017

Member

@bricss What feature(s) from V8 5.8 do you count on?

Member

targos commented Mar 9, 2017

@bricss What feature(s) from V8 5.8 do you count on?

@bricss

This comment has been minimized.

Show comment
Hide comment
@bricss

bricss Mar 9, 2017

WebAssembly should be enabled by default in V8 5.8 as I know.

bricss commented Mar 9, 2017

WebAssembly should be enabled by default in V8 5.8 as I know.

@targos

This comment has been minimized.

Show comment
Hide comment
@targos

targos Mar 9, 2017

Member

Yes, it is in 5.7:

$ ./node
> process.versions.v8
'5.7.492.63'
> WebAssembly.
WebAssembly.__defineGetter__      WebAssembly.__defineSetter__      WebAssembly.__lookupGetter__      WebAssembly.__lookupSetter__      WebAssembly.__proto__             WebAssembly.constructor           WebAssembly.hasOwnProperty        WebAssembly.isPrototypeOf
WebAssembly.propertyIsEnumerable  WebAssembly.toLocaleString        WebAssembly.toString              WebAssembly.valueOf               

WebAssembly.CompileError          WebAssembly.Instance              WebAssembly.LinkError             WebAssembly.Memory                WebAssembly.Module                WebAssembly.RuntimeError          WebAssembly.Table                 WebAssembly.compile
WebAssembly.instantiate           WebAssembly.validate              

Member

targos commented Mar 9, 2017

Yes, it is in 5.7:

$ ./node
> process.versions.v8
'5.7.492.63'
> WebAssembly.
WebAssembly.__defineGetter__      WebAssembly.__defineSetter__      WebAssembly.__lookupGetter__      WebAssembly.__lookupSetter__      WebAssembly.__proto__             WebAssembly.constructor           WebAssembly.hasOwnProperty        WebAssembly.isPrototypeOf
WebAssembly.propertyIsEnumerable  WebAssembly.toLocaleString        WebAssembly.toString              WebAssembly.valueOf               

WebAssembly.CompileError          WebAssembly.Instance              WebAssembly.LinkError             WebAssembly.Memory                WebAssembly.Module                WebAssembly.RuntimeError          WebAssembly.Table                 WebAssembly.compile
WebAssembly.instantiate           WebAssembly.validate              

@bricss

This comment has been minimized.

Show comment
Hide comment
@bricss

bricss Mar 9, 2017

Great, but also V8 5.8 would have performance improvements (new compilation pipeline) to deliver.

bricss commented Mar 9, 2017

Great, but also V8 5.8 would have performance improvements (new compilation pipeline) to deliver.

@targos targos added this to the 8.0.0 milestone Mar 9, 2017

@NawarA

This comment has been minimized.

Show comment
Hide comment
@NawarA

NawarA Mar 9, 2017

+1 on delaying the Node v8.0.0 <Carbon?> by one week or two week, to include V8 5.8.

We delayed Node v6 Boron by a tiny bit, so we could include V8 5.1, which included Orinoco and major performance boosts (like Fast For-In loops) when compared to V8 5.0. This future proofed v6 LTS during its life-cycle.

I recommend we combine the Node LTS April release with the April release of V8 5.8 to do the same kind of future proofing. I believe V8 5.8 is stable around April 25th

NawarA commented Mar 9, 2017

+1 on delaying the Node v8.0.0 <Carbon?> by one week or two week, to include V8 5.8.

We delayed Node v6 Boron by a tiny bit, so we could include V8 5.1, which included Orinoco and major performance boosts (like Fast For-In loops) when compared to V8 5.0. This future proofed v6 LTS during its life-cycle.

I recommend we combine the Node LTS April release with the April release of V8 5.8 to do the same kind of future proofing. I believe V8 5.8 is stable around April 25th

@addaleax addaleax referenced this pull request Mar 10, 2017

Closed

v8: expose new V8 5.5 serialization API #11048

4 of 4 tasks complete
@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Mar 10, 2017

Member

The 8.0.0 release will definitely go out in April. The current plan is the last week in April. If 5.8 is not ready by then, it won't make it. Hopefully it will be.

Member

jasnell commented Mar 10, 2017

The 8.0.0 release will definitely go out in April. The current plan is the last week in April. If 5.8 is not ready by then, it won't make it. Hopefully it will be.

@fhinkel

This comment has been minimized.

Show comment
Hide comment
@fhinkel

fhinkel Mar 10, 2017

Member

We removed the legacy JSON debugger protocol in V8 5.8. Not sure if including 5.8 in Node 8 would give people enough time to not rely on on the JSON protocol anymore.

Member

fhinkel commented Mar 10, 2017

We removed the legacy JSON debugger protocol in V8 5.8. Not sure if including 5.8 in Node 8 would give people enough time to not rely on on the JSON protocol anymore.

@NawarA

This comment has been minimized.

Show comment
Hide comment
@NawarA

NawarA Mar 10, 2017

@fhinkel its a semMAJOR update, so devs expect a breaking change.

@jasnell thanks! With 6 LTS, we pushed 5.1 into the branch after release it was released. If we can't get 5.8 in by release date, can we expect it to be released into 8 LTS, when its ready? We did this with 6 LTS, so there is precedent, so I imagine its an option here as well. Is this an option?

NawarA commented Mar 10, 2017

@fhinkel its a semMAJOR update, so devs expect a breaking change.

@jasnell thanks! With 6 LTS, we pushed 5.1 into the branch after release it was released. If we can't get 5.8 in by release date, can we expect it to be released into 8 LTS, when its ready? We did this with 6 LTS, so there is precedent, so I imagine its an option here as well. Is this an option?

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Mar 10, 2017

Member

There are no guarantees but we can try. As @fhinkel points out, dropping the debugger is a significant change and we need to give users a proper deprecation cycle to transition to the new --inspect. We also need to make sure there are no ABI breaking changes (which we currently do not expect but we'll need to see for sure). The CTC would be looking at it and making a decision.

And while semver-major releases allow for breaking changes, our preference -- and the preference of many users -- is for those breaking changes to be kept to a minimum as much as possible. The runtime deprecation warning for --debug only just landed in v7.x within the past week or two. It really is important that we give users an opportunity to transition.

Member

jasnell commented Mar 10, 2017

There are no guarantees but we can try. As @fhinkel points out, dropping the debugger is a significant change and we need to give users a proper deprecation cycle to transition to the new --inspect. We also need to make sure there are no ABI breaking changes (which we currently do not expect but we'll need to see for sure). The CTC would be looking at it and making a decision.

And while semver-major releases allow for breaking changes, our preference -- and the preference of many users -- is for those breaking changes to be kept to a minimum as much as possible. The runtime deprecation warning for --debug only just landed in v7.x within the past week or two. It really is important that we give users an opportunity to transition.

@icambron

This comment has been minimized.

Show comment
Hide comment
@icambron

icambron Mar 11, 2017

@jasnell I'm confused.

There are no guarantees but we can try.

That sounds like "if it's ready on time we can do it", whereas,

It really is important that we give users an opportunity to transition.

Sounds like "no, that is too abrupt, we need cut 8.0.0 without it regardless of its readiness". Can you clarify?

icambron commented Mar 11, 2017

@jasnell I'm confused.

There are no guarantees but we can try.

That sounds like "if it's ready on time we can do it", whereas,

It really is important that we give users an opportunity to transition.

Sounds like "no, that is too abrupt, we need cut 8.0.0 without it regardless of its readiness". Can you clarify?

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Mar 11, 2017

Member
Member

jasnell commented Mar 11, 2017

@mhdawson

This comment has been minimized.

Show comment
Hide comment
@mhdawson

mhdawson Mar 13, 2017

Member

CI run after update with fixes for linuxOne issues: https://ci.nodejs.org/job/node-test-pull-request/6824/

Member

mhdawson commented Mar 13, 2017

CI run after update with fixes for linuxOne issues: https://ci.nodejs.org/job/node-test-pull-request/6824/

@targos

This comment has been minimized.

Show comment
Hide comment
@targos

targos Mar 13, 2017

Member

node-test-commit-linuxone is green

Member

targos commented Mar 13, 2017

node-test-commit-linuxone is green

@targos

This comment has been minimized.

Show comment
Hide comment
@targos

targos Mar 21, 2017

Member

New CI: https://ci.nodejs.org/job/node-test-commit/8599/
Only Windows should fail.

Member

targos commented Mar 21, 2017

New CI: https://ci.nodejs.org/job/node-test-commit/8599/
Only Windows should fail.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Mar 22, 2017

Member

Just a quick reminder, I'm hoping to lock down the semver-major commits going into 8.0.0 by April 4th. Definitely going to give some leeway for the V8 update but we need time for a proper set or release candidates. The release is going out the last week in April.

Member

jasnell commented Mar 22, 2017

Just a quick reminder, I'm hoping to lock down the semver-major commits going into 8.0.0 by April 4th. Definitely going to give some leeway for the V8 update but we need time for a proper set or release candidates. The release is going out the last week in April.

@targos targos changed the title from WIP: deps: update V8 to 5.7 to deps: update V8 to 5.7 Mar 23, 2017

mhdawson and others added some commits May 9, 2016

deps: limit regress/regress-crbug-514081 v8 test
regress/regress-crbug-514081 allocates a 2G block of memory
and if there  are multiple variants running at the
same time this can lead to crashes, OOM kills or
the OS failing to allocate memory.  This patch
limits us to running a single variant of the test

Fixes: #6340
PR-URL: #6678
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
deps: cherry-pick V8 ValueSerializer changes
Refs: #11048

Below is the list of commits:

deps: cherry-pick 78c0be52d from V8 upstream

Original commit message:

  ValueSerializer: Promote scheduled exceptions from wasm::ErrorThrower.

  wasm::ErrorThrower doesn't actually throw exceptions, it just schedules them.
  As a result, this exception isn't handled properly by code which expects
  ValueDeserializer to actually throw. For instance, the unit tests use a
  TryCatch to catch and handle expected exceptions in unit tests.

  Before this patch, I see local unit test failures because a wasm decode test
  schedules one, but it isn't caught (and instead causes Context::New to fail
  at the beginning of the next test).

  BUG=685713

  Review-Url: https://codereview.chromium.org/2659483004
  Cr-Commit-Position: refs/heads/master@{#42718}

deps: cherry-pick 966355585 from V8 upstream

Original commit message:

  [d8] Use ValueSerializer for postMessage (instead of ad-hoc serializer)

  Review-Url: https://codereview.chromium.org/2643723010
  Cr-Commit-Position: refs/heads/master@{#42749}

deps: cherry-pick bf511b426 from V8 upstream

Original commit message:

  ValueSerializer: Support efficiently reading and writing one-byte strings.

  memcpy is faster than UTF-8 encoding/decoding. This yields 10-20% wins on
  serializing and deserializing long ASCII strings, according to
  blink_perf.bindings -- and these are already in a fast path where the entire
  string is known to be ASCII (but this has to be checked). The win may be
  larger for strings in Latin-1 but not ASCII (though I suspect this is an
  uncommon case).

  A change is also made to make ValueSerializerTest.EncodeTwoByteStringUsesPadding
  survive wire format version number changes.

  This is the first of a series of wire format changes from the previous Blink
  format. The deserializer continues to be able to read the old format, but
  Chromium M56 will no longer be able to read the messages written by this, in M58.

  BUG=chromium:686159

  Review-Url: https://codereview.chromium.org/2658793004
  Cr-Commit-Position: refs/heads/master@{#42753}

deps: cherry-pick 6f1639ed1 from V8 upstream

Original commit message:

  ValueSerializer: Distinguish between 'undefined' and an absent property.

  Dealing with this case requires a wire format change. It is possible that an
  element can be absent even in an array where the dense format was chosen
  (because the array initially had no holes), if the elements are modified while
  they are being serialized. In this case, a new tag for the "hole" is emitted.

  The logic to treat undefined in dense arrays as an absent property is restricted
  to versions of the wire format that this tag did not exist.

  BUG=chromium:686159,chromium:665820

  Review-Url: https://codereview.chromium.org/2660093002
  Cr-Original-Commit-Position: refs/heads/master@{#42784}
  Committed: https://chromium.googlesource.com/v8/v8/+/dc85f4c8338c1c824af4f7ee3274dc9f95d14e49
  Review-Url: https://codereview.chromium.org/2660093002
  Cr-Commit-Position: refs/heads/master@{#42800}

deps: cherry-pick c3856de37 from V8 upstream

Original commit message:

  ValueSerializer: Check for zero length before casting to FixedDoubleArray.

  Even though the elements kind is FAST_DOUBLE_ELEMENTS, if length is zero
  the isolate's empty_fixed_array is used. It's illegal to cast this to
  FixedDoubleArray, so we avoid the cast.

  BUG=chromium:686479

  Review-Url: https://codereview.chromium.org/2665313003
  Cr-Commit-Position: refs/heads/master@{#42867}

deps: cherry-pick 591cc0b4c from V8 upstream

Original commit message:

  ValueSerializer: Share string encoding code with String and RegExp objects.

  This avoids the need to pull in the UTF-8 encoding code from the public API,
  and allows it to take advantage of any supported way that i::String can be
  encoded (one- or two-byte).

  Backward compatibility is maintained, but this is the behavior beginning
  with this version.

  BUG=chromium:686159

  Review-Url: https://codereview.chromium.org/2665653004
  Cr-Commit-Position: refs/heads/master@{#42872}

deps: cherry-pick 79837f5f6 from V8 upstream

Original commit message:

  Improve ValueSerializer perf regression after 96635558

  BUG=687196
  R=jbroman@chromium.org

  Review-Url: https://codereview.chromium.org/2674613002
  Cr-Commit-Position: refs/heads/master@{#42938}

deps: cherry-pick 8990399dc from V8 upstream

Original commit message:

  ValueDeserializer: Only allow valid keys when deserializing object properties.

  The serializer won't ever write a more complex object. Not validating this
  allows other things to be used as keys, and converted to string when the
  property set actually occurs. It turns out this gives an opportunity to trigger
  OOM by giving an object a key which is a very large sparse array (whose string
  representation is very large).

  This case is now rejected by the deserializer.

  BUG=chromium:686511

  Review-Url: https://codereview.chromium.org/2697023002
  Cr-Commit-Position: refs/heads/master@{#43249}

deps: cherry-pick 68960eeb7 from V8 upstream

Original commit message:

  ValueDeserializer: Make sure that an exception is the legacy path.

  The entry points to the deserializer are responsible for ensuring that an
  exception is pending by the time they return. Some failures throw exceptions
  themselves, while others (like errors in the format) are exceptions caused by
  the deserializer, not coming from the runtime.

  Like the non-legacy path, a default deserialization exception should be thrown
  in such cases.

  BUG=chromium:693411

  Review-Url: https://codereview.chromium.org/2712713002
  Cr-Commit-Position: refs/heads/master@{#43390}

deps: cherry-pick 3b15d950e from V8 upstream

Original commit message:
  ValueSerializer: Add SetTreatArrayBufferViewsAsHostObjects() flag

  Add `ValueSerializer::SetTreatArrayBufferViewsAsHostObjects()` which
  instructs the `ValueSerializer` to treat ArrayBufferView objects as
  host objects.

  BUG=v8:5926

  Review-Url: https://codereview.chromium.org/2696133007
  Cr-Commit-Position: refs/heads/master@{#43281}

deps: cherry-pick 654351997 from V8 upstream

Original commit message:

  ValueSerializer: Add an explicit tag for host objects.

  This makes it no longer necessary to ensure that V8 and Blink have non-colliding
  tags, which makes it easier for them to evolve independently, and also makes
  the wire format more suitable for other V8 embedders, who would not
  necessarily be surveyed before V8 introduced a new tag that might collide
  with theirs.

  BUG=chromium:686159

  Review-Url: https://codereview.chromium.org/2709023003
  Cr-Commit-Position: refs/heads/master@{#43466}

PR-URL: #11752
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
deps: update V8 to 5.7.492.69
PR-URL: #11752
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
src: update NODE_MODULE_VERSION to 54
Major V8 updates are usually API/ABI incompatible with previous
versions. This commit adapts NODE_MODULE_VERSION for V8 5.7.

Refs: https://github.com/nodejs/CTC/blob/master/meetings/2016-09-28.md

PR-URL: #11752
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
deps: cherry-pick 0ba513f05 from V8 upstream
Original commit message:
  [api] Fix DescriptorInterceptor with access check.

  The DescriptorInterceptor should intercept all
  Object.getOwnPropertyDescriptor calls. This CL fixes
  the interceptor's behavior if the iterator state is
  ACCESS_CHECK.

  BUG=

  Review-Url: https://codereview.chromium.org/2707263002
  Cr-Commit-Position: refs/heads/master@{#43417}

PR-URL: #11712
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
deps: cherry-pick a927f81c7 from V8 upstream
Original commit message:

  [ValueSerializer] Allow wire format versions beginning with 13 to be deserialized in non-legacy mode.

  As of version 13, delegates do not need to worry about colliding tags with the
  tags reserved by v8, since v8 inserts a "host object" prefix beforehand. Thus
  the format is now suitable for more general use, without opting into the "legacy"
  mode that had this caveat.

  Review-Url: https://codereview.chromium.org/2722213002
  Cr-Commit-Position: refs/heads/master@{#43521}

PR-URL: #11752
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
deps: cherry-pick c5c570f from upstream V8
Original commit message:

    [build] Fix gyp files for building inspector

    This patch fixes compilation of V8 with inspector on Windows as well as
    cross-compilation of the V8 inspector.

    BUG=

    Refs: #10992
    Review-Url: https://codereview.chromium.org/2705423003
    Cr-Commit-Position: refs/heads/master@{#43533}

PR-URL: #11752
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
deps: backport 39642fa from upstream V8
This is an almost clean cherry-pick of the original commit. The only
conflict was related to a rename of an internal class.

Original commit message:

    [async-await] (simpler) fix for Return in try/finally in async functions

    Alternative approach to https://codereview.chromium.org/2667983004/, which
    does not depend on implicit control flow changes from
    https://codereview.chromium.org/2664083002

    - Remove handling for `async function` from Parser::RewriteReturn(). This functionality
    is moved to BytecodeGenerator::BuildAsyncReturn(). This ensures that promise resolution
    is deferred until all finally blocks are evaluated fully.

    - Add a new deferred command (CMD_ASYNC_RETURN), which instructs ControlScope to
    generate return code using BuildAsyncReturn rather than BuildReturn.

    - Parser has a new `NewReturnStatement()` helper which determines what type of return
    statement to generate based on the type of function.

    BUG=v8:5896, v8:4483
    R=littledan@chromium.org, neis@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, gsathya@chromium.org

    Review-Url: https://codereview.chromium.org/2685683002
    Cr-Commit-Position: refs/heads/master@{#43104}

Fixes: #11960
PR-URL: #11752
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
src: update inspector code to match upstream API
PR-URL: #11752
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
deps: backport 3297130 from upstream V8
This fixes a build failure on Windows.

Original commit message:

    Rename TypeFeedbackVector to FeedbackVector.

    ... and TypeFeedbackMetadata to FeedbackMetadata.

    BUG=

    Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
    Reviewed-on: https://chromium-review.googlesource.com/439244
    Commit-Queue: Igor Sheludko <ishell@chromium.org>
    Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
    Reviewed-by: Michael Stanton <mvstanton@chromium.org>
    Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
    Reviewed-by: Yang Guo <yangguo@chromium.org>
    Reviewed-by: Hannes Payer <hpayer@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#42999}

Refs: nodejs/v8#4
PR-URL: #11752
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>

@targos targos merged commit ed12ea3 into nodejs:master Mar 25, 2017

@jBarz jBarz referenced this pull request Mar 25, 2017

Closed

deps: backport 224d376 from V8 upstream #10526

2 of 2 tasks complete

@AndreasMadsen AndreasMadsen referenced this pull request Mar 28, 2017

Closed

async_hooks initial implementation #11883

3 of 4 tasks complete

@jasnell jasnell referenced this pull request Apr 4, 2017

Closed

8.0.0 Release Proposal #12220

@joaocgreis

This comment has been minimized.

Show comment
Hide comment
@joaocgreis

joaocgreis Apr 11, 2017

Member

This floating patch should no longer be needed with c1670b6 applied.

Member

joaocgreis commented on 9c9e2d7 Apr 11, 2017

This floating patch should no longer be needed with c1670b6 applied.

targos added a commit to targos/node that referenced this pull request May 6, 2017

deps: cherry-pick a927f81c7 from V8 upstream
Original commit message:

  [ValueSerializer] Allow wire format versions beginning with 13 to be deserialized in non-legacy mode.

  As of version 13, delegates do not need to worry about colliding tags with the
  tags reserved by v8, since v8 inserts a "host object" prefix beforehand. Thus
  the format is now suitable for more general use, without opting into the "legacy"
  mode that had this caveat.

  Review-Url: https://codereview.chromium.org/2722213002
  Cr-Commit-Position: refs/heads/master@{#43521}

PR-URL: nodejs#11752
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>

targos added a commit that referenced this pull request May 6, 2017

deps: cherry-pick a927f81c7 from V8 upstream
Original commit message:

  [ValueSerializer] Allow wire format versions beginning with 13 to be deserialized in non-legacy mode.

  As of version 13, delegates do not need to worry about colliding tags with the
  tags reserved by v8, since v8 inserts a "host object" prefix beforehand. Thus
  the format is now suitable for more general use, without opting into the "legacy"
  mode that had this caveat.

  Review-Url: https://codereview.chromium.org/2722213002
  Cr-Commit-Position: refs/heads/master@{#43521}

PR-URL: #11752
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>

anchnk added a commit to anchnk/node that referenced this pull request May 19, 2017

deps: cherry-pick a927f81c7 from V8 upstream
Original commit message:

  [ValueSerializer] Allow wire format versions beginning with 13 to be deserialized in non-legacy mode.

  As of version 13, delegates do not need to worry about colliding tags with the
  tags reserved by v8, since v8 inserts a "host object" prefix beforehand. Thus
  the format is now suitable for more general use, without opting into the "legacy"
  mode that had this caveat.

  Review-Url: https://codereview.chromium.org/2722213002
  Cr-Commit-Position: refs/heads/master@{#43521}

PR-URL: nodejs#11752
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>

@targos targos deleted the targos:v8-5.7 branch Jun 1, 2017

@jaimecbernardo jaimecbernardo referenced this pull request Jun 28, 2017

Closed

deps,win: set MSVS .obj folders in gyp for V8 #13959

2 of 2 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment