meta: merge node/master into node-chakracore/master

Merge 03b8ac1 as of 2017-12-26
This commit was automatically generated. For any problems, please contact jackhorton

Reviewed-By: Taylor Woll <tawoll@ntdev.microsoft.com>

.mailmap

@@ -188,6 +188,8 @@ Kathy Truong <kathy.yvy.truong@gmail.com> k3kathy <kathy.yvy.truong@gmail.com>
 Kazuyuki Yamada <tasogare.pg@gmail.com>
 Keith M Wesolowski <wesolows@joyent.com> <wesolows@foobazco.org>
 Kelsey Breseman <ifoundthemeaningoflife@gmail.com>
+Khaidi Chu <admin@xcoder.in> XadillaX <admin@xcoder.in>
+Khaidi Chu <admin@xcoder.in> <i@2333.moe>
 Kiyoshi Nomo <tokyoincidents.g@gmail.com> kysnm <tokyoincidents.g@gmail.com>
 Koichi Kobayashi <koichik@improvement.jp>
 Kris Kowal <kris.kowal@cixar.com>
@@ -264,6 +266,7 @@ Roman Klauke <romaaan.git@gmail.com> <romankl@users.noreply.github.com>
 Roman Reiss <me@silverwind.io>
 Ron Korving <ron@ronkorving.nl> <rkorving@wizcorp.jp>
 Ron Korving <ron@ronkorving.nl> ronkorving <ron@ronkorving.nl>
+Ruben Bridgewater <ruben@bridgewater.de> <ruben.bridgewater@fintura.de>
 Russell Dempsey <sgtpooki@gmail.com> <SgtPooki@gmail.com>
 Ryan Dahl <ry@tinyclouds.org>
 Ryan Emery <seebees@gmail.com>

AUTHORS

@@ -911,7 +911,7 @@ HUANG Wei <grubbyfans@gmail.com>
 DC <dcposch@dcpos.ch>
 Daniel Turing <mail@danielturing.com>
 Julie Pagano <julie.pagano@gmail.com>
-Ruben Bridgewater <ruben.bridgewater@fintura.de>
+Ruben Bridgewater <ruben@bridgewater.de>
 Felix Becker <felix.b@outlook.com>
 Igor Klopov <igor@klopov.com>
 Tsarevich Dmitry <dimhotepus@users.noreply.github.com>
@@ -1493,7 +1493,7 @@ Sreepurna Jasti <sreepurna.jasti@gmail.com>
 Rafael Fragoso <rafaelfragosom@gmail.com>
 Andrei Cioromila <andrei.cioromila@gmail.com>
 Frank Lanitz <frank@frank.uvena.de>
-XadillaX <admin@xcoder.in>
+Khaidi Chu <admin@xcoder.in>
 Akshay Iyer <c.m.akshay.iyer@gmail.com>
 Rick Bullotta <RickBullotta@users.noreply.github.com>
 Rajaram Gaunker <zimbabao@gmail.com>
@@ -1532,7 +1532,6 @@ Dan Homola <dan.homola@hotmail.cz>
 cornholio <0@mcornholio.ru>
 Tamás Hódi <tamas.hodi@risingstack.com>
 DuanPengfei <2459714173@qq.com>
-Ruben Bridgewater <ruben@bridgewater.de>
 Lakshmi Swetha Gopireddy <lakshmiswethagopireddy@gmail.com>
 Rob Wu <rob@robwu.nl>
 Steven Winston <swinston100@hotmail.com>
@@ -2036,5 +2035,34 @@ Hannes Magnusson <hannes.magnusson@creditkarma.com>
 ChungNgoops <mr.mvagusta@gmail.com>
 Jose M. Palacios Diaz <jmpd1988@gmail.com>
 hmammedzadeh <hasan.mammed-zadeh@commercetools.de>
+IHsuan <frostyjoan0829@livemail.tw>
+Francisco Gerardo Neri Andriano <on_neri@hotmail.com>
+Shilo Mangam <smangam@gmail.com>
+idandagan1 <idandagan1@gmail.com>
+Cameron Moorehead <hello@cameronmoorehead.com>
+TomerOmri <tomer92@gmail.com>
+Collins Abitekaniza <abtcolns@gmail.com>
+Federico Kauffman <fede.kau@gmail.com>
+Benno Fünfstück <benno.fuenfstueck@gmail.com>
+Ram Goli <ramsgoli@gmail.com>
+babygoat <babygoat1124@gmail.com>
+Will Clark <willclarktech@users.noreply.github.com>
+Jem Bezooyen <jem@hipmedia.ca>
+Haejin Jo <professionalhaejin@gmail.com>
+Hakan Kimeiga <hak7alp@gmail.com>
+Tyler <tyler.z.yang@gmail.com>
+Shinya Kanamaru <mn131bb@gmail.com>
+you12724 <you12724@gmail.com>
+routerman <h.okano.looz@gmail.com>
+April Webster <awebster@us.ibm.com>
+Jure Triglav <juretriglav@gmail.com>
+alnyan <qShadowp@gmail.com>
+rt33 <rt33@lastcycle.com>
+Ulmanb <barulman@gmail.com>
+xortiz <xavier.ortiz.ch@gmail.com>
+Waleed Ashraf <waleedashraf@outlook.com>
+Mir Mufaqam Ali <mannanali413@gmail.com>
+Nicholas Drane <nicholasdrane@gmail.com>
+Shobhit Chittora <chittorashobhit@gmail.com>
 
 # Generated by tools/update-authors.sh

doc/api/console.md

@@ -103,70 +103,33 @@ The global `console` is a special `Console` whose output is sent to
 new Console(process.stdout, process.stderr);
 ```
 
-### console.assert(value[, message][, ...args])
+### console.assert(value[, ...message])
 <!-- YAML
 added: v0.1.101
+changes:
+  - version: REPLACEME
+    pr-url: https://github.com/nodejs/node/pull/REPLACEME
+    description: The implementation is now spec compliant and does not throw
+                 anymore.
 -->
-* `value` {any}
-* `message` {any}
-* `...args` {any}
+* `value` {any} The value tested for being truthy.
+* `...message` {any} All arguments besides `value` are used as error message.
 
 A simple assertion test that verifies whether `value` is truthy. If it is not,
-an `AssertionError` is thrown. If provided, the error `message` is formatted
-using [`util.format()`][] and used as the error message.
+`Assertion failed` is logged. If provided, the error `message` is formatted
+using [`util.format()`][] by passing along all message arguments. The output is
+used as the error message.
 
 ```js
 console.assert(true, 'does nothing');
 // OK
-console.assert(false, 'Whoops %s', 'didn\'t work');
-// AssertionError: Whoops didn't work
+console.assert(false, 'Whoops %s work', 'didn\'t');
+// Assertion failed: Whoops didn't work
 ```
 
-*Note*: The `console.assert()` method is implemented differently in Node.js
-than the `console.assert()` method [available in browsers][web-api-assert].
-
-Specifically, in browsers, calling `console.assert()` with a falsy
-assertion will cause the `message` to be printed to the console without
-interrupting execution of subsequent code. In Node.js, however, a falsy
-assertion will cause an `AssertionError` to be thrown.
-
-Functionality approximating that implemented by browsers can be implemented
-by extending Node.js' `console` and overriding the `console.assert()` method.
-
-In the following example, a simple module is created that extends and overrides
-the default behavior of `console` in Node.js.
-
-<!-- eslint-disable func-name-matching -->
-```js
-'use strict';
-
-// Creates a simple extension of console with a
-// new impl for assert without monkey-patching.
-const myConsole = Object.create(console, {
-  assert: {
-    value: function assert(assertion, message, ...args) {
-      try {
-        console.assert(assertion, message, ...args);
-      } catch (err) {
-        console.error(err.stack);
-      }
-    },
-    configurable: true,
-    enumerable: true,
-    writable: true,
-  },
-});
-
-module.exports = myConsole;
-```
-
-This can then be used as a direct replacement for the built in console:
-
-```js
-const console = require('./myConsole');
-console.assert(false, 'this message will print, but no error thrown');
-console.log('this will also print');
-```
+*Note*: Calling `console.assert()` with a falsy assertion will only cause the
+`message` to be printed to the console without interrupting execution of
+subsequent code.
 
 ### console.clear()
 <!-- YAML
@@ -531,4 +494,3 @@ This method does not display anything unless used in the inspector. The
 [customizing `util.inspect()` colors]: util.html#util_customizing_util_inspect_colors
 [inspector]: debugger.html
 [note on process I/O]: process.html#process_a_note_on_process_i_o
-[web-api-assert]: https://developer.mozilla.org/en-US/docs/Web/API/console/assert

doc/guides/building-node-with-ninja.md

@@ -1,28 +1,36 @@
 # Building Node with Ninja
 
-The purpose of this guide is to show how to build Node.js using [Ninja][], as doing so can be significantly quicker than using `make`. Please see [Ninja's site][Ninja] for installation instructions (unix only).
+The purpose of this guide is to show how to build Node.js using [Ninja][], as
+doing so can be significantly quicker than using `make`. Please see
+[Ninja's site][Ninja] for installation instructions (unix only).
 
 To build Node with ninja, there are 3 steps that must be taken:
 
 1. Configure the project's OS-based build rules via `./configure --ninja`.
 2. Run `ninja -C out/Release` to produce a compiled release binary.
 3. Lastly, make symlink to `./node` using `ln -fs out/Release/node node`.
 
-When running `ninja -C out/Release` you will see output similar to the following if the build has succeeded:
+When running `ninja -C out/Release` you will see output similar to the following
+if the build has succeeded:
+
 ```txt
 ninja: Entering directory `out/Release`
 [4/4] LINK node, POSTBUILDS
 ```
 
-The bottom line will change while building, showing the progress as `[finished/total]` build steps.
-This is useful output that `make` does not produce and is one of the benefits of using Ninja.
-Also, Ninja will likely compile much faster than even `make -j4` (or `-j<number of processor threads on your machine>`).
+The bottom line will change while building, showing the progress as
+`[finished/total]` build steps. This is useful output that `make` does not
+produce and is one of the benefits of using Ninja. Also, Ninja will likely
+compile much faster than even `make -j4` (or
+`-j<number of processor threads on your machine>`).
 
 ## Considerations
 
-Ninja builds vary slightly from `make` builds. If you wish to run `make test` after, `make` will likely still need to rebuild some amount of Node.
+Ninja builds vary slightly from `make` builds. If you wish to run `make test`
+after, `make` will likely still need to rebuild some amount of Node.
 
-As such, if you wish to run the tests, it can be helpful to invoke the test runner directly, like so:
+As such, if you wish to run the tests, it can be helpful to invoke the test
+runner directly, like so:
 `tools/test.py --mode=release message parallel sequential -J`
 
 ## Alias
@@ -31,7 +39,8 @@ As such, if you wish to run the tests, it can be helpful to invoke the test runn
 
 ## Producing a debug build
 
-The above alias can be modified slightly to produce a debug build, rather than a release build as shown below:
+The above alias can be modified slightly to produce a debug build, rather than a
+release build as shown below:
 `alias nnodedebug='./configure --ninja && ninja -C out/Debug && ln -fs out/Debug/node node_g'`
 
 

doc/guides/maintaining-V8.md

@@ -157,8 +157,8 @@ process.
 
 * Unfixed bugs. The bug exists in the V8 master branch.
 * Fixed, but needs backport. The bug may need porting to one or more branches.
-    * Backporting to active branches.
-    * Backporting to abandoned branches.
+  * Backporting to active branches.
+  * Backporting to abandoned branches.
 * Backports identified by the V8 team. Bugs identified by upstream V8 that we
   haven't encountered in Node.js yet.
 
@@ -188,14 +188,14 @@ backport the fix:
 * Identify which version of V8 the bug was fixed in.
 * Identify if any active V8 branches still contain the bug:
 * A tracking bug is needed to request a backport.
-    * If there isn't already a V8 bug tracking the fix, open a new merge request
-      bug using this [Node.js specific template][V8TemplateMergeRequest].
-    * If a bug already exists
-        * Add a reference to the GitHub issue.
-        * Attach *merge-request-x.x* labels to the bug for any active branches
-          that still contain the bug. (e.g. merge-request-5.3,
-          merge-request-5.4)
-        * Add ofrobots-at-google.com to the cc list.
+  * If there isn't already a V8 bug tracking the fix, open a new merge request
+    bug using this [Node.js specific template][V8TemplateMergeRequest].
+  * If a bug already exists
+    * Add a reference to the GitHub issue.
+    * Attach *merge-request-x.x* labels to the bug for any active branches
+      that still contain the bug. (e.g. merge-request-5.3,
+      merge-request-5.4)
+    * Add ofrobots-at-google.com to the cc list.
 * Once the merge has been approved, it should be merged using the
   [merge script documented in the V8 wiki][V8MergingPatching]. Merging requires
   commit access to the V8 repository. If you don't have commit access you can
@@ -214,24 +214,24 @@ to be cherry-picked in the Node.js repository and V8-CI must test the change.
 
 * For each abandoned V8 branch corresponding to an LTS branch that is affected
   by the bug:
-    * Checkout a branch off the appropriate *vY.x-staging* branch (e.g.
-      *v6.x-staging* to fix an issue in V8 5.1).
-    * Cherry-pick the commit(s) from the V8 repository.
-    * On Node.js < 9.0.0: Increase the patch level version in `v8-version.h`.
-      This will not cause any problems with versioning because V8 will not
-      publish other patches for this branch, so Node.js can effectively bump the
-      patch version.
-    * On Node.js >= 9.0.0: Increase the `v8_embedder_string` number in
-      `common.gypi`.
-    * In some cases the patch may require extra effort to merge in case V8 has
-      changed substantially. For important issues we may be able to lean on the
-      V8 team to get help with reimplementing the patch.
-    * Open a cherry-pick PR on `nodejs/node` targeting the *vY.x-staging* branch
-      and notify the `@nodejs/v8` team.
-    * Run the Node.js [V8 CI] in addition to the [Node.js CI].
-      Note: The CI uses the `test-v8` target in the `Makefile`, which uses
-      `tools/make-v8.sh` to reconstruct a git tree in the `deps/v8` directory to
-      run V8 tests.
+  * Checkout a branch off the appropriate *vY.x-staging* branch (e.g.
+    *v6.x-staging* to fix an issue in V8 5.1).
+  * Cherry-pick the commit(s) from the V8 repository.
+  * On Node.js < 9.0.0: Increase the patch level version in `v8-version.h`.
+    This will not cause any problems with versioning because V8 will not
+    publish other patches for this branch, so Node.js can effectively bump the
+    patch version.
+  * On Node.js >= 9.0.0: Increase the `v8_embedder_string` number in
+    `common.gypi`.
+  * In some cases the patch may require extra effort to merge in case V8 has
+    changed substantially. For important issues we may be able to lean on the
+    V8 team to get help with reimplementing the patch.
+  * Open a cherry-pick PR on `nodejs/node` targeting the *vY.x-staging* branch
+    and notify the `@nodejs/v8` team.
+  * Run the Node.js [V8 CI] in addition to the [Node.js CI].
+    Note: The CI uses the `test-v8` target in the `Makefile`, which uses
+    `tools/make-v8.sh` to reconstruct a git tree in the `deps/v8` directory to
+    run V8 tests.
 
 The [`update-v8`] tool can be used to simplify this task. Run
 `update-v8 backport --sha=SHA` to cherry-pick a commit.
@@ -275,6 +275,7 @@ Original commit message:
 Refs: https://github.com/v8/v8/commit/a51f429772d1e796744244128c9feeab4c26a854
 PR-URL: https://github.com/nodejs/node/pull/7833
 ```
+
 * Open a PR against the `v6.x-staging` branch in the Node.js repo. Launch the
   normal and [V8 CI] using the Node.js CI system. We only needed to backport to
   `v6.x` as the other LTS branches weren't affected by this bug.

doc/guides/maintaining-npm.md

@@ -21,7 +21,9 @@ $ git checkout vX.Y.Z
 $ make release
 ```
 
-Note: please run `npm dist-tag ls npm` and make sure this is the `latest` **dist-tag**. `latest` on git is usually released as `next` when it's time to downstream
+Note: please run `npm dist-tag ls npm` and make sure this is the `latest`
+**dist-tag**. `latest` on git is usually released as `next` when it's time to
+downstream
 
 ## Step 3: Remove old npm
 

doc/guides/writing-and-running-benchmarks.md

@@ -144,6 +144,7 @@ arrays/zero-int.js n=25 type=Buffer: 90.49906662339653
 ```
 
 It is possible to execute more groups by adding extra process arguments.
+
 ```console
 $ node benchmark/run.js arrays buffers
 ```
@@ -439,6 +440,7 @@ function main(conf) {
 ```
 
 Supported options keys are:
+
 * `port` - defaults to `common.PORT`
 * `path` - defaults to `/`
 * `connections` - number of concurrent connections to use, defaults to 100

doc/guides/writing-tests.md

@@ -238,8 +238,8 @@ const freelist = require('internal/freelist');
 
 When writing assertions, prefer the strict versions:
 
-* `assert.strictEqual()` over `assert.equal()`
-* `assert.deepStrictEqual()` over `assert.deepEqual()`
+- `assert.strictEqual()` over `assert.equal()`
+- `assert.deepStrictEqual()` over `assert.deepEqual()`
 
 When using `assert.throws()`, if possible, provide the full error message:
 
@@ -263,9 +263,9 @@ in each release.
 
 For example:
 
-* `let` and `const` over `var`
-* Template literals over string concatenation
-* Arrow functions when appropriate
+- `let` and `const` over `var`
+- Template literals over string concatenation
+- Arrow functions when appropriate
 
 ## Naming Test Files
 
@@ -306,12 +306,14 @@ the upstream project, send another PR here to update Node.js accordingly.
 Be sure to update the hash in the URL following `WPT Refs:`.
 
 ## C++ Unit test
+
 C++ code can be tested using [Google Test][]. Most features in Node.js can be
 tested using the methods described previously in this document. But there are
 cases where these might not be enough, for example writing code for Node.js
 that will only be called when Node.js is embedded.
 
 ### Adding a new test
+
 The unit test should be placed in `test/cctest` and be named with the prefix
 `test` followed by the name of unit being tested. For example, the code below
 would be placed in `test/cctest/test_env.cc`:
@@ -345,18 +347,21 @@ static void at_exit_callback(void* arg) {
 ```
 
 Next add the test to the `sources` in the `cctest` target in node.gyp:
+
 ```console
 'sources': [
   'test/cctest/test_env.cc',
   ...
 ],
 ```
+
 Note that the only sources that should be included in the cctest target are
 actual test or helper source files. There might be a need to include specific
 object files that are compiled by the `node` target and this can be done by
 adding them to the `libraries` section in the cctest target.
 
 The test can be executed by running the `cctest` target:
+
 ```console
 $ make cctest
 ```