nodejs · mmmscott · Oct 12, 2018 · Oct 10, 2018 · Oct 12, 2018 · Oct 12, 2018
diff --git a/.gitignore b/.gitignore
@@ -133,3 +133,5 @@ deps/uv/docs/src/guide/
 deps/v8/gypfiles/Debug/
 deps/v8/gypfiles/Release/
 deps/v8/third_party/eu-strip/
+
+.DS_Store
diff --git a/BUILDING.md b/BUILDING.md
@@ -10,40 +10,42 @@ file a new issue.
 
 ## Table of Contents
 
-* [Supported platforms](#supported-platforms)
-  * [Input](#input)
-  * [Strategy](#strategy)
-  * [Supported platforms](#supported-platforms-1)
-  * [Supported toolchains](#supported-toolchains)
-    * [Unix](#unix)
-    * [AIX](#aix)
-    * [Windows](#windows)
-    * [OpenSSL asm support](#openssl-asm-support)
-* [Building Node.js on supported platforms](#building-nodejs-on-supported-platforms)
-  * [Unix/macOS](#unixmacos)
-    * [Prerequisites](#prerequisites)
-    * [Building Node.js](#building-nodejs-1)
-    * [Running Tests](#running-tests)
-    * [Building the documentation](#building-the-documentation)
-    * [Building a debug build](#building-a-debug-build)
-  * [Windows](#windows-1)
-  * [Android/Android-based devices (e.g. Firefox OS)](#androidandroid-based-devices-eg-firefox-os)
-  * [`Intl` (ECMA-402) support](#intl-ecma-402-support)
-    * [Default: `small-icu` (English only) support](#default-small-icu-english-only-support)
-    * [Build with full ICU support (all locales supported by ICU)](#build-with-full-icu-support-all-locales-supported-by-icu)
-      * [Unix/macOS](#unixmacos-1)
-      * [Windows](#windows-2)
-    * [Building without Intl support](#building-without-intl-support)
-      * [Unix/macOS](#unixmacos-2)
-      * [Windows](#windows-3)
-    * [Use existing installed ICU (Unix/macOS only)](#use-existing-installed-icu-unixmacos-only)
-    * [Build with a specific ICU](#build-with-a-specific-icu)
-      * [Unix/macOS](#unixmacos-3)
-      * [Windows](#windows-4)
-* [Building Node.js with FIPS-compliant OpenSSL](#building-nodejs-with-fips-compliant-openssl)
-* [Building Node.js with external core modules](#building-nodejs-with-external-core-modules)
-  * [Unix/macOS](#unixmacos-4)
-  * [Windows](#windows-5)
+- [Building Node.js](#building-nodejs)
+  - [Table of Contents](#table-of-contents)
+  - [Supported platforms](#supported-platforms)
+    - [Input](#input)
+    - [Strategy](#strategy)
+    - [Supported platforms](#supported-platforms)
+    - [Supported toolchains](#supported-toolchains)
+      - [Unix](#unix)
+      - [AIX](#aix)
+      - [Windows](#windows)
+      - [OpenSSL asm support](#openssl-asm-support)
+  - [Building Node.js on supported platforms](#building-nodejs-on-supported-platforms)
+    - [Unix/macOS](#unixmacos)
+      - [Prerequisites](#prerequisites)
+      - [Building Node.js](#building-nodejs)
+      - [Running Tests](#running-tests)
+      - [Building the documentation](#building-the-documentation)
+      - [Building a debug build](#building-a-debug-build)
+    - [Windows](#windows)
+    - [Android/Android-based devices (e.g. Firefox OS)](#androidandroid-based-devices-eg-firefox-os)
+    - [`Intl` (ECMA-402) support:](#intl-ecma-402-support)
+      - [Default: `small-icu` (English only) support](#default-small-icu-english-only-support)
+      - [Build with full ICU support (all locales supported by ICU):](#build-with-full-icu-support-all-locales-supported-by-icu)
+        - [Unix/macOS:](#unixmacos)
+        - [Windows:](#windows)
+      - [Building without Intl support](#building-without-intl-support)
+        - [Unix/macOS:](#unixmacos)
+        - [Windows:](#windows)
+      - [Use existing installed ICU (Unix/macOS only):](#use-existing-installed-icu-unixmacos-only)
+      - [Build with a specific ICU:](#build-with-a-specific-icu)
+        - [Unix/macOS](#unixmacos)
+        - [Windows](#windows)
+  - [Building Node.js with FIPS-compliant OpenSSL](#building-nodejs-with-fips-compliant-openssl)
+  - [Building Node.js with external core modules](#building-nodejs-with-external-core-modules)
+    - [Unix/macOS](#unixmacos)
+    - [Windows](#windows)
 
 ## Supported platforms
 
@@ -52,8 +54,7 @@ which it is attached.
 
 ### Input
 
-Node.js relies on V8 and libuv. Therefore, we adopt a subset of their
-supported platforms.
+Node.js relies on V8 and libuv. We adopt a subset of their supported platforms.
 
 ### Strategy
 
@@ -74,19 +75,19 @@ The community does not build or test against end-of-life distributions (EoL).
 Thus, we do not recommend that you use Node on end-of-life or unsupported
 platforms in production.
 
-|  System      | Support type | Version                          | Architectures        | Notes            |
-|--------------|--------------|----------------------------------|----------------------|------------------|
-| GNU/Linux    | Tier 1       | kernel >= 2.6.32, glibc >= 2.12  | x64, arm             |                  |
-| GNU/Linux    | Tier 1       | kernel >= 3.10, glibc >= 2.17    | arm64                |                  |
-| macOS/OS X   | Tier 1       | >= 10.11                         | x64                  |                  |
-| Windows      | Tier 1       | >= Windows 7/2008 R2/2012 R2     | x86, x64             | [2](#fn2),[3](#fn3),[4](#fn4) |
-| SmartOS      | Tier 2       | >= 15 < 16.4                     | x86, x64             | [1](#fn1) |
-| FreeBSD      | Tier 2       | >= 11                            | x64                  |                  |
-| GNU/Linux    | Tier 2       | kernel >= 3.13.0, glibc >= 2.19  | ppc64le >=power8     |                  |
-| AIX          | Tier 2       | >= 7.1 TL04                      | ppc64be >=power7     |                  |
-| GNU/Linux    | Tier 2       | kernel >= 3.10, glibc >= 2.17    | s390x                |                  |
-| GNU/Linux    | Experimental | kernel >= 2.6.32, glibc >= 2.12  | x86                  | limited CI       |
-| Linux (musl) | Experimental | musl >= 1.0                      | x64                  |                  |
+| System       | Support type | Version                         | Architectures    | Notes                         |
+| ------------ | ------------ | ------------------------------- | ---------------- | ----------------------------- |
+| GNU/Linux    | Tier 1       | kernel >= 2.6.32, glibc >= 2.12 | x64, arm         |                               |
+| GNU/Linux    | Tier 1       | kernel >= 3.10, glibc >= 2.17   | arm64            |                               |
+| macOS/OS X   | Tier 1       | >= 10.11                        | x64              |                               |
+| Windows      | Tier 1       | >= Windows 7/2008 R2/2012 R2    | x86, x64         | [2](#fn2),[3](#fn3),[4](#fn4) |
+| SmartOS      | Tier 2       | >= 15 < 16.4                    | x86, x64         | [1](#fn1)                     |
+| FreeBSD      | Tier 2       | >= 11                           | x64              |                               |
+| GNU/Linux    | Tier 2       | kernel >= 3.13.0, glibc >= 2.19 | ppc64le >=power8 |                               |
+| AIX          | Tier 2       | >= 7.1 TL04                     | ppc64be >=power7 |                               |
+| GNU/Linux    | Tier 2       | kernel >= 3.10, glibc >= 2.17   | s390x            |                               |
+| GNU/Linux    | Experimental | kernel >= 2.6.32, glibc >= 2.12 | x86              | limited CI                    |
+| Linux (musl) | Experimental | musl >= 1.0                     | x64              |                               |
 
 <em id="fn1">1</em>: The gcc4.8-libs package needs to be installed, because node
   binaries have been built with GCC 4.8, for which runtime libraries are not
@@ -111,8 +112,8 @@ platforms in production.
   community will only address issues that reproduce on native GNU/Linux
   systems. Issues that only reproduce on WSL should be reported in the
   [WSL issue tracker](https://github.com/Microsoft/WSL/issues). Running the
-  Windows binary (`node.exe`) in WSL is not recommended, and will not work
-  without adjustment (such as stdio redirection).
+  Windows binary (`node.exe`) in WSL is not recommended. It will not work
+  without workarounds such as stdio redirection.
 
 ### Supported toolchains
 
@@ -144,10 +145,8 @@ Otherwise `configure` will fail with an error. This can be avoided by
 either providing a newer assembler as per the list above or by
 using the `--openssl-no-asm` flag.
 
-*Note:* The forthcoming OpenSSL-1.1.1 will require higher
- version. Please refer
- https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_ia32cap.html for
- details.
+The forthcoming OpenSSL-1.1.1 will have different requirements. Please refer to
+ https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_ia32cap.html for details.
 
 ## Building Node.js on supported platforms
 
@@ -216,7 +215,7 @@ $ make test-only
 
 At this point, you are ready to make code changes and re-run the tests.
 
-If you are running tests prior to submitting a Pull Request, the recommended
+If you are running tests before submitting a Pull Request, the recommended
 command is:
 
 ```console
@@ -226,6 +225,32 @@ $ make -j4 test
 `make -j4 test` does a full check on the codebase, including running linters and
 documentation tests.
 
+If you are updating tests and just want to run a single test to check it:
+
+```text
+$ python tools/test.py -J --mode=release parallel/test-stream2-transform
+```
+
+You can execute the entire suite of tests for a given subsystem
+by providing the name of a subsystem:
+
+```text
+$ python tools/test.py -J --mode=release child-process
+```
+
+If you want to check the other options, please refer to the help by using
+the `--help` option
+
+```text
+$ python tools/test.py --help
+```
+
+You can usually run tests directly with node:
+
+```text
+$ ./node ./test/parallel/test-stream2-transform.js
+```
+
 Optionally, continue below.
 
 To run the tests and generate code coverage reports:
@@ -344,7 +369,7 @@ Prerequisites:
   and tools which can be included in the global `PATH`.
 * The [NetWide Assembler](http://www.nasm.us/), for OpenSSL assembler modules.
   If not installed in the default location, it needs to be manually added
-  to `PATH`. Build with `openssl-no-asm` option does not require this.
+  to `PATH`. A build with the `openssl-no-asm` option does not need this.
 * **Optional** (to build the MSI): the [WiX Toolset v3.11](http://wixtoolset.org/releases/)
   and the [Wix Toolset Visual Studio 2017 Extension](https://marketplace.visualstudio.com/items?itemName=RobMensching.WixToolsetVisualStudio2017Extension).
 
@@ -369,12 +394,10 @@ To test if Node.js was built correctly:
 
 ### Android/Android-based devices (e.g. Firefox OS)
 
-Although these instructions for building on Android are provided, please note
-that Android is not an officially supported platform at this time. Patches to
-improve the Android build are accepted. However, there is no testing on Android
-in the current continuous integration environment. The participation of people
-dedicated and determined to improve Android building, testing, and support is
-encouraged.
+Android is not a supported platform. Patches to improve the Android build are
+welcome. There is no testing on Android in the current continuous integration
+environment. The participation of people dedicated and determined to improve
+Android building, testing, and support is encouraged.
 
 Be sure you have downloaded and extracted
 [Android NDK](https://developer.android.com/tools/sdk/ndk/index.html) before in

diff --git a/COLLABORATOR_GUIDE.md b/COLLABORATOR_GUIDE.md
@@ -100,7 +100,8 @@ As soon as the PR is ready to land, please do so. Landing your own pull requests
 allows other Collaborators to focus on other pull requests. If your pull request
 is still awaiting the [minimum time to land](#waiting-for-approvals), add the
 `author ready` label so other Collaborators know it can land as soon as the time
-ends.
+ends. If instead you wish to land the PR yourself, indicate this intent by using
+the "assign yourself" button, to self-assign the PR.
 
 ## Accepting Modifications
 
@@ -501,12 +502,16 @@ The TSC should serve as the final arbiter where required.
 
 ## Landing Pull Requests
 
+1. Avoid landing PRs that are assigned to someone else. Authors who wish to land
+   their own PRs will self-assign them, or delegate to someone else. If in
+   doubt, ask the assignee whether it is okay to land.
 1. Never use GitHub's green ["Merge Pull Request"][] button. Reasons for not
    using the web interface button:
-   * The merge method will add an unnecessary merge commit.
-   * The squash & merge method can add metadata (the PR #) to the commit title.
-   * If more than one author has contributed to the PR, keep the most recent
-     author when squashing.
+   * The "Create a merge commit" method will add an unnecessary merge commit.
+   * The "Squash and merge" method will add metadata (the PR #) to the commit
+     title. If more than one author has contributed to the PR, squashing will
+     only keep the most recent author.
+   * The "Rebase and merge" method has no way of adding metadata to the commit.
 1. Make sure the CI is done and the result is green. If the CI is not green,
    check for flaky tests and infrastructure failures. Please check if those were
    already reported in the appropriate repository ([node][flaky tests] and
@@ -517,13 +522,12 @@ The TSC should serve as the final arbiter where required.
    present.
 1. Review the commit message to ensure that it adheres to the guidelines
    outlined in the [contributing][] guide.
-1. Add all necessary [metadata](#metadata) to commit messages before landing.
-   See the commit log for examples such as [this
-   one](https://github.com/nodejs/node/commit/b636ba8186) if unsure exactly how
-   to format your commit messages.
+1. Add all necessary [metadata](#metadata) to commit messages before landing. If
+   you are unsure exactly how to format the commit messages, use the commit log
+   as a reference. See [this commit][commit-example] as an example.
 
-Check PRs from new contributors to make sure the person's name and email address
-are correct before merging.
+For PRs from first time contributors, be [welcoming](#welcoming-first-time-contributors).
+Also, verify that their git settings are to their liking.
 
 All commits should be self-contained, meaning every commit should pass all
 tests. This makes it much easier when bisecting to find a breaking change.
@@ -901,6 +905,7 @@ If you cannot find who to cc for a file, `git shortlog -n -s <file>` may help.
 [`node-core-utils`]: https://github.com/nodejs/node-core-utils
 [backporting guide]: doc/guides/backporting-to-release-lines.md
 [contributing]: ./doc/guides/contributing/pull-requests.md#commit-message-guidelines
+[commit-example]: https://github.com/nodejs/node/commit/b636ba8186
 [flaky tests]: https://github.com/nodejs/node/issues?q=is%3Aopen+is%3Aissue+label%3A%22CI+%2F+flaky+test%22y
 [git-node]: https://github.com/nodejs/node-core-utils/blob/master/docs/git-node.md
 [git-node-metadata]: https://github.com/nodejs/node-core-utils/blob/master/docs/git-node.md#git-node-metadata

diff --git a/CPP_STYLE_GUIDE.md b/CPP_STYLE_GUIDE.md
@@ -2,6 +2,7 @@
 
 ## Table of Contents
 
+* [Guides and References](#guides-and-references)
 * [Formatting](#formatting)
   * [Left-leaning (C++ style) asterisks for pointer declarations](#left-leaning-c-style-asterisks-for-pointer-declarations)
   * [C++ style comments](#c-style-comments)
@@ -25,14 +26,30 @@
   * [Avoid throwing JavaScript errors in C++ methods](#avoid-throwing-javascript-errors-in-c)
     * [Avoid throwing JavaScript errors in nested C++ methods](#avoid-throwing-javascript-errors-in-nested-c-methods)
 
-Unfortunately, the C++ linter (based on
-[Google’s `cpplint`](https://github.com/google/styleguide)), which can be run
-explicitly via `make lint-cpp`, does not currently catch a lot of rules that are
-specific to the Node.js C++ code base. This document explains the most common of
-these rules:
+
+## Guides and References
+
+The Node.js C++ codebase strives to be consistent in its use of language
+features and idioms, as well as have some specific guidelines for the use of
+runtime features.
+
+Coding guidelines are based on the following guides (highest priority first):
+1. This document
+2. The [Google C++ Style Guide][]
+3. The ISO [C++ Core Guidelines][]
+
+In general code should follow the C++ Core Guidelines, unless overridden by the
+Google C++ Style Guide or this document. At the moment these guidelines are
+checked manually by reviewers, with the goal to validate this with automatic
+tools.
 
 ## Formatting
 
+Unfortunately, the C++ linter (based on [Google’s `cpplint`][]), which can be
+run explicitly via `make lint-cpp`, does not currently catch a lot of rules that
+are specific to the Node.js C++ code base. This document explains the most
+common of these rules:
+
 ### Left-leaning (C++ style) asterisks for pointer declarations
 
 `char* buffer;` instead of `char *buffer;`
@@ -304,4 +321,8 @@ not inside of nested calls.
 
 Using C++ `throw` is not allowed.
 
+
+[C++ Core Guidelines]: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
+[Google C++ Style Guide]: https://google.github.io/styleguide/cppguide.html
+[Google’s `cpplint`]: https://github.com/google/styleguide
 [errors]: https://github.com/nodejs/node/blob/master/doc/guides/using-internal-errors.md
diff --git a/benchmark/common.js b/benchmark/common.js
@@ -242,3 +242,13 @@ Benchmark.prototype.report = function(rate, elapsed) {
     type: 'report'
   });
 };
+
+exports.binding = function(bindingName) {
+  try {
+    const { internalBinding } = require('internal/test/binding');
+
+    return internalBinding(bindingName);
+  } catch {
+    return process.binding(bindingName);
+  }
+};
diff --git a/benchmark/http/bench-parser.js b/benchmark/http/bench-parser.js
@@ -10,8 +10,7 @@ const bench = common.createBenchmark(main, {
 });
 
 function main({ len, n }) {
-  const { internalBinding } = require('internal/test/binding');
-  const { HTTPParser } = internalBinding('http_parser');
+  const { HTTPParser } = common.binding('http_parser');
   const REQUEST = HTTPParser.REQUEST;
   const kOnHeaders = HTTPParser.kOnHeaders | 0;
   const kOnHeadersComplete = HTTPParser.kOnHeadersComplete | 0;

diff --git a/benchmark/misc/punycode.js b/benchmark/misc/punycode.js
@@ -3,7 +3,7 @@
 const common = require('../common.js');
 let icu;
 try {
-  icu = process.binding('icu');
+  icu = common.binding('icu');
 } catch (err) {}
 const punycode = require('punycode');
 

diff --git a/benchmark/misc/trace.js b/benchmark/misc/trace.js
@@ -11,7 +11,7 @@ const bench = common.createBenchmark(main, {
 
 const {
   TRACE_EVENT_PHASE_NESTABLE_ASYNC_BEGIN: kBeforeEvent
-} = process.binding('constants').trace;
+} = common.binding('constants').trace;
 
 function doTrace(n, trace) {
   bench.start();
@@ -31,12 +31,10 @@ function doIsTraceCategoryEnabled(n, isTraceCategoryEnabled) {
 }
 
 function main({ n, method }) {
-  const { internalBinding } = require('internal/test/binding');
-
   const {
     trace,
     isTraceCategoryEnabled
-  } = internalBinding('trace_events');
+  } = common.binding('trace_events');
 
   switch (method) {
     case '':