deps: upgrade to V8 4.7.80.24 #4106
Conversation
|
What about the semver label for this update ? |
|
As per the V8 API changes doc there shouldn't be embedder-exposed API changes in 4.7. |
|
I thought 4.7 would go into master as semver-major and be released with Node v6.0.0 in April of 2016. |
|
Won't we be way past 4.7 by April though? |
|
Well yea, there would be other V8 updates along the way. |
Not at the API level but Which is a shame because otherwise it could have been a semver-minor in v5.x. |
|
LGTM |
|
Wasn't the whole reason why io.js was born the fact that Node was falling way behind on ES6? If we stick V8 releases to semver major (and I get the argument, I really do), don't we fall into the same hole, because major releases are pegged to predetermined release dates? |
|
@nodejs/build: From the CI, I cannot seem to access the jenkins results page for the lone failure on centos5-32. I consistently get '504 Gateway Timeout'. I can't know if it is a real failure or a flake. Any ideas? |
|
@ofrobots damn, thought I was able to fix all those timeouts. Looking at the raw log (https://ci.nodejs.org/job/node-test-commit-linux/nodes=centos5-32/ws/test.tap/*view*/) I can't see anything strange. |
|
not sure if thats a bug in the tap parser, can't find a single |
|
sorry the timeouts probably coincided with a couple of restarts I did |
To some extent maybe, but at least the release dates are predictable now and the release cycles short(er). Apropos the 4.7 upgrade, what we could do (although I'm not sure if it's a good idea), is to apply some fixes to maintain ABI compatibility. I believe it's mostly a matter of moving some enums around. Thoughts? |
|
I might be in the minority, but I like the idea of taking a new V8 in major versions, even if there are no breaking changes for native modules. My reasoning is the addition of new language features. As a userland module author, it is simpler to say "we will start using these new features, bump our own major version, and support this version of Node" when it is a major version bump. The hapi ecosystem did exactly this with Node 4 and its new ES6 features. |
|
@cjihrig you're suggesting bringing the latest v8 into stable? |
|
@trevnorris I'm suggesting only taking new V8s in major version bumps regardless of semver implications. So, in this case, not taking 4.7+ until Node 6.0.0. |
|
@cjihrig I think feature testing is a better way to do language feature testing. JS devs, both on the browser and on Node.js are already familiar with how this works. What hapi team did is not really the norm, and shouldn't be used as the reason to hold back semver-minor features from other developers. Also, whether a semver-minor feature is 'part of the language' or not is a rather arbitrary distinction given how user-modifiable the language is. @bnoordhuis Re: fixing the ABI compatibility issues. It is do-able. Back-porting fixes from upstream could theoretically become harder, but only if there is an actual conflict with our changes (not likely). I don't know there is any system-integrator (Debian?) that integrates Node with a system wide V8 library? We won't be ABI compatible with that version. Not sure if any such integrators exist. |
|
I'd like us to take V8 stables into master, we still haven't figured out our master/canary/next strategy but I'm under the assumption that most of us would like to have downloadable builds off master of some kind so that bleeding-edge types can use them and prepare us for the next stable release. I've been planning on starting a bikeshed on how to achieve this, I'll try and get to it asap and start a new issue for discussion but I was imagining something like automatic weekly builds with version numbers that make it clear it's not 5.x but it's also not quite 6.x and library authors shouldn't feel the need to support it yet. |
|
I'm definitely not opposed to this landing in master, in case there was any confusion about that.
Language feature detection is a huge pain. Rest parameters are in 4.7, right? You can't even load a file containing a rest parameter in current Node. Then you either have to maintain multiple versions of your code or use a transpiler. |
|
The long v0.11 saga is actually pretty instructive for us when considering a master release strategy and looking forward to further divergence between LTS and stable. There were open source libraries and even actual production deployments that were strictly v0.11-only because of some of the features available there and the fact that there was no v0.12 in sight. There were also many open source libraries that explicitly refused to add any support for v0.11 until v0.12 actually came out, we experienced a lot of that when trying to help add NAN support to addons (that mostly wore away as it started to look like we would never even see a v0.12). I'm confident in the ecosystem's ability to adapt to the differences between versions and come up with both clever technical solutions and also policy solutions that will be suitable for different kinds of users. It may end up looking a little like a split but that's not such a bad thing and it'll work out over time with different users gravitating to different libraries and different policies over time. I have a lot of faith in our massive and very adaptive community to figure out how best to handle it; the best we can do is observe and respond with support where needed. |
|
@rvagg should we kick off a thread in the Build WG about a Canary strategy? |
|
If this does make it into a release, please make it a canary one... at least until 6.0.0 ships. It doesn't make sense for code written on 5.x.x to not work on 5.x.x... amiright |
|
@geek yes of course, we're not going to break semver for this |
|
I am going to land this PR to |
|
LGTM |
|
rubber-stamp lgtm |
Original commit message:
This commit adds some postmortem data that is otherwise unavailable.
I have discovered need in those values when writing:
https://github.com/indutny/llnode
BUG=
Review URL: https://codereview.chromium.org/1436473002
Cr-Commit-Position: refs/heads/master@{nodejs#31947}
This postmortem information is useful for both object inspection, and
function's context variables inspection.
Ref: nodejs#3779
PR-URL: nodejs#4106
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: rvagg - Rod Vagg <rod@vagg.org>
Original commit message: [tools] Make gen-postmortem-metadata.py more reliable Instead of basing matches off of whitespace, walk the inheritance chain and include any classes that inherit from Object. R=machenbach@chromium.org,jkummerow@chromium.org NOTRY=true Review URL: https://codereview.chromium.org/1435643002 Cr-Commit-Position: refs/heads/master@{nodejs#31964} This adds some missing classes to postmortem info like JSMap and JSSet. Ref: nodejs#3792 PR-URL: nodejs#4106 Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com> Reviewed-By: rvagg - Rod Vagg <rod@vagg.org>
Original commit message:
This commit adds some postmortem data that is otherwise unavailable.
I have discovered need in those values when writing:
https://github.com/indutny/llnode
BUG=
Review URL: https://codereview.chromium.org/1436473002
Cr-Commit-Position: refs/heads/master@{nodejs#31947}
This postmortem information is useful for both object inspection, and
function's context variables inspection.
Ref: nodejs#3779
PR-URL: nodejs#4106
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: rvagg - Rod Vagg <rod@vagg.org>
Original commit message: [tools] Make gen-postmortem-metadata.py more reliable Instead of basing matches off of whitespace, walk the inheritance chain and include any classes that inherit from Object. R=machenbach@chromium.org,jkummerow@chromium.org NOTRY=true Review URL: https://codereview.chromium.org/1435643002 Cr-Commit-Position: refs/heads/master@{nodejs#31964} This adds some missing classes to postmortem info like JSMap and JSSet. Ref: nodejs#3792 PR-URL: nodejs#4106 Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com> Reviewed-By: rvagg - Rod Vagg <rod@vagg.org>
Original commit message:
This commit adds some postmortem data that is otherwise unavailable.
I have discovered need in those values when writing:
https://github.com/indutny/llnode
BUG=
Review URL: https://codereview.chromium.org/1436473002
Cr-Commit-Position: refs/heads/master@{#31947}
This postmortem information is useful for both object inspection, and
function's context variables inspection.
Ref: #3779
PR-URL: #4106
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: rvagg - Rod Vagg <rod@vagg.org>
Original commit message: [tools] Make gen-postmortem-metadata.py more reliable Instead of basing matches off of whitespace, walk the inheritance chain and include any classes that inherit from Object. R=machenbach@chromium.org,jkummerow@chromium.org NOTRY=true Review URL: https://codereview.chromium.org/1435643002 Cr-Commit-Position: refs/heads/master@{#31964} This adds some missing classes to postmortem info like JSMap and JSSet. Ref: #3792 PR-URL: #4106 Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com> Reviewed-By: rvagg - Rod Vagg <rod@vagg.org>
Pick up the latest branch head for V8 4.7: v8/v8@be169f8 Full change history for the 4.7 branch: https://chromium.googlesource.com/v8/v8.git/+log/branch-heads/4.7 V8 blog post about what is new on V8 4.7: http://v8project.blogspot.de/2015/10/v8-release-47.html PR-URL: nodejs#4106 Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com> Reviewed-By: rvagg - Rod Vagg <rod@vagg.org>
Array#includes is now available. Ref: nodejs#3481 PR-URL: nodejs#4106 Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com> Reviewed-By: rvagg - Rod Vagg <rod@vagg.org>
Backport 1ee712ab8687e5f4dec93d45da068d37d28feb8b from V8 upstream.
Original commit message:
Add SetAbortOnUncaughtExceptionCallback API
The --abort-on-uncaught-exception command line switch makes
Isolate::Throw abort if the error being thrown cannot be caught by a
try/catch block.
Embedders may want to use other mechanisms than try/catch blocks to
handle uncaught exceptions. For instance, Node.js has "domain" objects
that have error handlers that can handle uncaught exception like
following:
var d = domain.create();
d.on('error', function onError(err) {
console.log('Handling error');
});
d.run(function() {
throw new Error("boom");
});
These error handlers are called by isolates' message listeners.
If --abort-on-uncaught-exception is *not* used, the isolate's
message listener will be called, which will in turn call the domain's
error handler. The process will output 'Handling error' and will exit
successfully (not due to an uncaught exception). This is the behavior
that Node.js users expect.
However, if --abort-on-uncaught-exception is used and when throwing an
error within a domain that has an error handler, the process will abort
and the domain's error handler will not be called. This is not the
behavior that Node.js users expect.
Having a SetAbortOnUncaughtExceptionCallback API allows embedders to
determine when it's not appropriate to abort and instead handle the
exception via the isolate's message listener.
In the example above, Node.js would set a custom callback with
SetAbortOnUncaughtExceptionCallback that would be implemented as
following (the sample code has been simplified to remove what's not
relevant to this change):
bool ShouldAbortOnUncaughtException(Isolate* isolate) {
return !IsDomainActive();
}
Now when --abort-on-uncaught-exception is used, Isolate::Throw would
call that callback and determine that it should not abort if a domain
with an error handler is active. Instead, the isolate's message listener
would be called and the error would be handled by the domain's error
handler.
I believe this can also be useful for other embedders.
BUG=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1375933003
Cr-Commit-Position: refs/heads/master@{nodejs#31111}
Ref: nodejs#3036
Ref: nodejs#3481
PR-URL: nodejs#4106
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: rvagg - Rod Vagg <rod@vagg.org>
Original commit message:
This commit adds some postmortem data that is otherwise unavailable.
I have discovered need in those values when writing:
https://github.com/indutny/llnode
BUG=
Review URL: https://codereview.chromium.org/1436473002
Cr-Commit-Position: refs/heads/master@{nodejs#31947}
This postmortem information is useful for both object inspection, and
function's context variables inspection.
Ref: nodejs#3779
PR-URL: nodejs#4106
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: rvagg - Rod Vagg <rod@vagg.org>
Original commit message: [tools] Make gen-postmortem-metadata.py more reliable Instead of basing matches off of whitespace, walk the inheritance chain and include any classes that inherit from Object. R=machenbach@chromium.org,jkummerow@chromium.org NOTRY=true Review URL: https://codereview.chromium.org/1435643002 Cr-Commit-Position: refs/heads/master@{nodejs#31964} This adds some missing classes to postmortem info like JSMap and JSSet. Ref: nodejs#3792 PR-URL: nodejs#4106 Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com> Reviewed-By: rvagg - Rod Vagg <rod@vagg.org>
Original commit message:
This commit adds some postmortem data that is otherwise unavailable.
I have discovered need in those values when writing:
https://github.com/indutny/llnode
BUG=
Review URL: https://codereview.chromium.org/1436473002
Cr-Commit-Position: refs/heads/master@{nodejs#31947}
This postmortem information is useful for both object inspection, and
function's context variables inspection.
Ref: nodejs#3779
PR-URL: nodejs#4106
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: rvagg - Rod Vagg <rod@vagg.org>
Original commit message: [tools] Make gen-postmortem-metadata.py more reliable Instead of basing matches off of whitespace, walk the inheritance chain and include any classes that inherit from Object. R=machenbach@chromium.org,jkummerow@chromium.org NOTRY=true Review URL: https://codereview.chromium.org/1435643002 Cr-Commit-Position: refs/heads/master@{nodejs#31964} This adds some missing classes to postmortem info like JSMap and JSSet. Ref: nodejs#3792 PR-URL: nodejs#4106 Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com> Reviewed-By: rvagg - Rod Vagg <rod@vagg.org>
This commit documents Node.js compatibility for function rest parameters. This mainly depends on V8 but I tracked the relevant Node versions, commits and PRs. Flagged support (V8 4.4): - [Node.js changelog entry for version 3.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_IOJS.md#2015-08-04-version-300-rvagg) - [Pull Request](nodejs/node#2022) - [Commit, with anchor to relevant line](nodejs/node@70d1f32f56#diff-b2e04de0d939630d882245c2243e7e47R200) Stable support (V8 4.7): - [Node.js changelog entry for version 6.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V6.md#2016-04-26-version-600-current-jasnell) - [Pull Request](nodejs/node#4106) - [Commit, with anchor to relevant line](nodejs/node@8a43a3d#diff-b2e04de0d939630d882245c2243e7e47R217) Flag removal (V8 4.9): - [Node.js changelog entry for version 6.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V6.md#2016-04-26-version-600-current-jasnell) - [Pull Request](nodejs/node#4722) - [Commit, with anchor to relevant line](nodejs/node@069e02a#diff-b2e04de0d939630d882245c2243e7e47L221)
This commit documents Node.js compatibility for function rest parameters. This mainly depends on V8 but I tracked the relevant Node versions, commits and PRs. Note that I used `4` for the version of the flag addition because `3` corresponds to the io.js fork and is not recognized as a valid `nodejs` version by the linter. Flagged support (io.js 3.0.0, V8 4.4): - [Node.js changelog entry for version 3.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_IOJS.md#2015-08-04-version-300-rvagg) - [Pull Request](nodejs/node#2022) - [Commit, with anchor to relevant line](nodejs/node@70d1f32f56#diff-b2e04de0d939630d882245c2243e7e47R200) Stable support (Node.js 6.0.0, V8 4.7): - [Node.js changelog entry for version 6.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V6.md#2016-04-26-version-600-current-jasnell) - [Pull Request](nodejs/node#4106) - [Commit, with anchor to relevant line](nodejs/node@8a43a3d#diff-b2e04de0d939630d882245c2243e7e47R217) Flag removal (Node.js 6.0.0, V8 4.9): - [Node.js changelog entry for version 6.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V6.md#2016-04-26-version-600-current-jasnell) - [Pull Request](nodejs/node#4722) - [Commit, with anchor to relevant line](nodejs/node@069e02a#diff-b2e04de0d939630d882245c2243e7e47L221)
Flagged support: - [Node.js changelog entry for version 3.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_IOJS.md#2015-08-04-version-300-rvagg) - [Pull Request](nodejs/node#2022) - [Commit, with anchor to relevant line](nodejs/node@70d1f32f56#diff-b2e04de0d939630d882245c2243e7e47R200) Stable support: - [Node.js changelog entry for version 6.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V6.md#2016-04-26-version-600-current-jasnell) - [Pull Request](nodejs/node#4106) - [Commit, with anchor to relevant line](nodejs/node@8a43a3d#diff-b2e04de0d939630d882245c2243e7e47R217)
Flagged support: - [Node.js changelog entry for version 3.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_IOJS.md#2015-08-04-version-300-rvagg) - [Pull Request](nodejs/node#2022) - [Commit, with anchor to relevant line](nodejs/node@70d1f32f56#diff-b2e04de0d939630d882245c2243e7e47R200) Stable support: - [Node.js changelog entry for version 6.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V6.md#2016-04-26-version-600-current-jasnell) - [Pull Request](nodejs/node#4106) - [Commit, with anchor to relevant line](nodejs/node@8a43a3d#diff-b2e04de0d939630d882245c2243e7e47R217) Flag removal: - [Node.js changelog entry for version 6.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V6.md#2016-04-26-version-600-current-jasnell) - [Pull Request](nodejs/node#4722) - [Commit, with anchor to relevant line](nodejs/node@069e02a#diff-b2e04de0d939630d882245c2243e7e47L221)
This commit documents Node.js compatibility for function rest parameters. This mainly depends on V8 but I tracked the relevant Node versions, commits and PRs. Flagged support (V8 4.4): - [Node.js changelog entry for version 3.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_IOJS.md#2015-08-04-version-300-rvagg) - [Pull Request](nodejs/node#2022) - [Commit, with anchor to relevant line](nodejs/node@70d1f32f56#diff-b2e04de0d939630d882245c2243e7e47R200) Stable support (V8 4.7): - [Node.js changelog entry for version 6.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V6.md#2016-04-26-version-600-current-jasnell) - [Pull Request](nodejs/node#4106) - [Commit, with anchor to relevant line](nodejs/node@8a43a3d#diff-b2e04de0d939630d882245c2243e7e47R217) Flag removal (V8 4.9): - [Node.js changelog entry for version 6.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V6.md#2016-04-26-version-600-current-jasnell) - [Pull Request](nodejs/node#4722) - [Commit, with anchor to relevant line](nodejs/node@069e02a#diff-b2e04de0d939630d882245c2243e7e47L221)
* Update nodejs compat for javascript.function.rest_parameters This commit documents Node.js compatibility for function rest parameters. This mainly depends on V8 but I tracked the relevant Node versions, commits and PRs. Note that I used `4` for the version of the flag addition because `3` corresponds to the io.js fork and is not recognized as a valid `nodejs` version by the linter. Flagged support (io.js 3.0.0, V8 4.4): - [Node.js changelog entry for version 3.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_IOJS.md#2015-08-04-version-300-rvagg) - [Pull Request](nodejs/node#2022) - [Commit, with anchor to relevant line](nodejs/node@70d1f32f56#diff-b2e04de0d939630d882245c2243e7e47R200) Stable support (Node.js 6.0.0, V8 4.7): - [Node.js changelog entry for version 6.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V6.md#2016-04-26-version-600-current-jasnell) - [Pull Request](nodejs/node#4106) - [Commit, with anchor to relevant line](nodejs/node@8a43a3d#diff-b2e04de0d939630d882245c2243e7e47R217) Flag removal (Node.js 6.0.0, V8 4.9): - [Node.js changelog entry for version 6.0.0](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V6.md#2016-04-26-version-600-current-jasnell) - [Pull Request](nodejs/node#4722) - [Commit, with anchor to relevant line](nodejs/node@069e02a#diff-b2e04de0d939630d882245c2243e7e47L221)
Ref: #4085
Now that V8 4.7 has hit stable [0], this PR brings V8 4.7 onto master.
The PR includes all the cherry-picks from
vee-eight-4.7annd additionally 70405d4 was cherry-picked back frommaster.Full change history for the 4.7 branch:
https://chromium.googlesource.com/v8/v8.git/+log/branch-heads/4.7
V8 blog post about what is new on V8 4.7:
http://v8project.blogspot.de/2015/10/v8-release-47.html
R=@bnoordhuis, @targos
/cc @misterdjules, @nodejs/v8
/cc @nodejs/build as this probably effects beta builds.
[0] http://googlechromereleases.blogspot.com/2015/12/stable-channel-update.html