[v10.x] Update libuv to 1.27.0

.eslintrc.js

@@ -222,6 +222,7 @@ module.exports = {
       variables: false,
     }],
     'no-useless-call': 'error',
+    'no-useless-catch': 'error',
     'no-useless-concat': 'error',
     'no-useless-constructor': 'error',
     'no-useless-escape': 'error',

.travis.yml

@@ -1,6 +1,7 @@
 language: cpp
 cache: ccache
 os: linux
+dist: xenial
 matrix:
   include:
     - name: "First commit message adheres to guidelines at <a href=\"https://goo.gl/p2fr5Q\">https://goo.gl/p2fr5Q</a>"
@@ -24,9 +25,9 @@ matrix:
           sources:
             - ubuntu-toolchain-r-test
           packages:
-            - g++-4.9
+            - g++-6
       install:
-        - export CC='ccache gcc-4.9' CXX='ccache g++-4.9' JOBS=2
+        - export CC='ccache gcc-6' CXX='ccache g++-6' JOBS=2
         - ./configure
         - make -j2 V=
       script:

CHANGELOG.md

@@ -2,6 +2,8 @@
 
 Select a Node.js version below to view the changelog history:
 
+* [Node.js 12](doc/changelogs/CHANGELOG_V12.md) - **Current**
+* [Node.js 11](doc/changelogs/CHANGELOG_V11.md) - Current
 * [Node.js 10](doc/changelogs/CHANGELOG_V10.md) — **Long Term Support**
 * [Node.js 9](doc/changelogs/CHANGELOG_V9.md) — End-of-Life
 * [Node.js 8](doc/changelogs/CHANGELOG_V8.md) — Long Term Support
@@ -20,12 +22,17 @@ release.
 <!--lint disable maximum-line-length-->
 <table>
 <tr>
-  <th title="Current"><a href="doc/changelogs/CHANGELOG_V10.md">10</a><sup>Current</sup></th>
+  <th title="Current"><a href="doc/changelogs/CHANGELOG_V12.md">12</a><sup>Current</sup></th>
+  <th title="LTS Until 2021-04"><a href="doc/changelogs/CHANGELOG_V10.md">10</a><sup>LTS</sup></th>
   <th title="LTS Until 2019-12"><a href="doc/changelogs/CHANGELOG_V8.md">8</a><sup>LTS</sup></th>
   <th title="LTS Until 2019-04"><a href="doc/changelogs/CHANGELOG_V6.md">6</a><sup>LTS</sup></th>
 </tr>
 <tr>
     <td valign="top">
+<b><a href="doc/changelogs/CHANGELOG_V12.md#12.1.0">12.1.0</a></b><br/>
+<a href="doc/changelogs/CHANGELOG_V12.md#12.0.0">12.0.0</a><br/>
+    </td>
+    <td valign="top">
 <b><a href="doc/changelogs/CHANGELOG_V10.md#10.15.3">10.15.3</a></b><br/>
 <a href="doc/changelogs/CHANGELOG_V10.md#10.15.2">10.15.2</a><br/>
 <a href="doc/changelogs/CHANGELOG_V10.md#10.15.1">10.15.1</a><br/>
@@ -51,7 +58,17 @@ release.
 <a href="doc/changelogs/CHANGELOG_V10.md#10.0.0">10.0.0</a><br/>
     </td>
     <td valign="top">
-<b><a href="doc/changelogs/CHANGELOG_V8.md#8.11.1">8.11.1</a></b><br/>
+<b><a href="doc/changelogs/CHANGELOG_V8.md#8.16.0">8.16.0</a></b><br/>
+<a href="doc/changelogs/CHANGELOG_V8.md#8.15.1">8.15.1</a><br/>
+<a href="doc/changelogs/CHANGELOG_V8.md#8.15.0">8.15.0</a><br/>
+<a href="doc/changelogs/CHANGELOG_V8.md#8.14.1">8.14.1</a><br/>
+<a href="doc/changelogs/CHANGELOG_V8.md#8.14.0">8.14.0</a><br/>
+<a href="doc/changelogs/CHANGELOG_V8.md#8.13.0">8.13.0</a><br/>
+<a href="doc/changelogs/CHANGELOG_V8.md#8.12.0">8.12.0</a><br/>
+<a href="doc/changelogs/CHANGELOG_V8.md#8.11.4">8.11.4</a><br/>
+<a href="doc/changelogs/CHANGELOG_V8.md#8.11.3">8.11.3</a><br/>
+<a href="doc/changelogs/CHANGELOG_V8.md#8.11.2">8.11.2</a><br/>
+<a href="doc/changelogs/CHANGELOG_V8.md#8.11.1">8.11.1</a><br/>
 <a href="doc/changelogs/CHANGELOG_V8.md#8.11.0">8.11.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V8.md#8.10.0">8.10.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V8.md#8.9.4">8.9.4</a><br/>
@@ -75,45 +92,6 @@ release.
 <a href="doc/changelogs/CHANGELOG_V8.md#8.1.0">8.1.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V8.md#8.0.0">8.0.0</a><br/>
     </td>
-  <td valign="top">
-<b><a href="doc/changelogs/CHANGELOG_V6.md#6.14.1">6.14.1</a></b><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.14.0">6.14.0</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.13.1">6.13.1</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.13.0">6.13.0</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.12.3">6.12.3</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.12.2">6.12.2</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.12.1">6.12.1</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.12.0">6.12.0</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.11.5">6.11.5</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.11.4">6.11.4</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.11.3">6.11.3</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.11.2">6.11.2</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.11.1">6.11.1</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.11.0">6.11.0</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.10.3">6.10.3</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.10.2">6.10.2</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.10.1">6.10.1</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.10.0">6.10.0</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.9.5">6.9.5</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.9.4">6.9.4</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.9.3">6.9.3</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.9.2">6.9.2</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.9.1">6.9.1</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.9.0">6.9.0</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.8.1">6.8.1</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.8.0">6.8.0</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.7.0">6.7.0</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.6.0">6.6.0</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.5.0">6.5.0</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.4.0">6.4.0</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.3.1">6.3.1</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.3.0">6.3.0</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.2.2">6.2.2</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.2.1">6.2.1</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.2.0">6.2.0</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.1.0">6.1.0</a><br/>
-<a href="doc/changelogs/CHANGELOG_V6.md#6.0.0">6.0.0</a><br/>
-  </td>
 </tr>
 </table>
 

COLLABORATOR_GUIDE.md

@@ -256,62 +256,28 @@ Examples of breaking changes include:
 
 #### Breaking Changes and Deprecations
 
-With a few exceptions outlined below, when backward-incompatible changes to a
-*Public* API are necessary, the existing API *must* be deprecated *first* and
-the new API either introduced in parallel or added after the next major Node.js
-version following the deprecation as a replacement for the deprecated API. In
-other words, as a general rule, existing *Public* APIs *must not* change (in a
-backward-incompatible way) without a deprecation.
+Existing stable public APIs that change in a backward-incompatible way must
+undergo deprecation. The exceptions to this rule are:
 
-Exceptions to this rule may be made in the following cases:
-
-* Adding or removing errors thrown or reported by a Public API;
+* Adding or removing errors thrown or reported by a public API;
 * Changing error messages for errors without error code;
-* Altering the timing and non-internal side effects of the Public API.
-
-Such changes *must* be handled as semver-major changes but MAY be landed
-without a [Deprecation cycle](#deprecation-cycle).
-
-Note that errors thrown, along with behaviors and APIs implemented by
-dependencies of Node.js (e.g. those originating from V8) are generally not
-under the control of Node.js and therefore *are not directly subject to this
-policy*. However, care should still be taken when landing updates to
-dependencies when it is known or expected that breaking changes to error
-handling may have been made. Additional CI testing may be required.
-
-From time-to-time, in particularly exceptional cases, the TSC may be asked to
-consider and approve additional exceptions to this rule.
+* Altering the timing and non-internal side effects of the public API;
+* Changes to errors thrown by dependencies of Node.js, such as V8;
+* One-time exceptions granted by the TSC.
 
 For more information, see [Deprecations](#deprecations).
 
 #### Breaking Changes to Internal Elements
 
-Breaking changes to internal elements are permitted in semver-patch or
-semver-minor commits but Collaborators should take significant care when
-making and reviewing such changes. Before landing such commits, an effort
-must be made to determine the potential impact of the change in the ecosystem
-by analyzing current use and by validating such changes through ecosystem
-testing using the [Canary in the Goldmine](https://github.com/nodejs/citgm)
-tool. If a change cannot be made without ecosystem breakage, then TSC review is
-required before landing the change as anything less than semver-major.
-
-If a determination is made that a particular internal API (for instance, an
-underscore `_` prefixed property) is sufficiently relied upon by the ecosystem
-such that any changes may break user code, then serious consideration should be
-given to providing an alternative Public API for that functionality before any
-breaking changes are made.
+Breaking changes to internal elements may occur in semver-patch or semver-minor
+commits. Take significant care when making and reviewing such changes. Make
+an effort to determine the potential impact of the change in the ecosystem. Use
+[Canary in the Goldmine](https://github.com/nodejs/citgm) to test such changes.
+If a change will cause ecosystem breakage, then it is semver-major. Consider
+providing a Public API in such cases.
 
 #### When Breaking Changes Actually Break Things
 
-Because breaking (semver-major) changes are permitted to land on the master
-branch at any time, at least some subset of the user ecosystem may be adversely
-affected in the short term when attempting to build and use Node.js directly
-from the master branch. This potential instability is why Node.js offers
-distinct Current and LTS release streams that offer explicit stability
-guarantees.
-
-Specifically:
-
 * Breaking changes should *never* land in Current or LTS except when:
   * Resolving critical security issues.
   * Fixing a critical bug (e.g. fixing a memory leak) requires a breaking
@@ -687,62 +653,33 @@ git push upstream master
   messages. You are only allowed to force push to any Node.js branch within 10
   minutes from your original push. If someone else pushes to the branch or the
   10-minute period passes, consider the commit final.
-  * Use `--force-with-lease` to minimize the chance of overwriting
-  someone else's change.
+  * Use `--force-with-lease` to reduce the chance of overwriting someone else's
+    change.
   * Post to `#node-dev` (IRC) if you force push.
 
 ### Long Term Support
 
 #### What is LTS?
 
-Long Term Support (often referred to as *LTS*) guarantees application developers
-a 30-month support cycle with specific versions of Node.js.
-
-You can find more information
-[in the full release plan](https://github.com/nodejs/Release#release-plan).
-
-#### How does LTS work?
-
-Once a Current branch enters LTS, changes in that branch are limited to bug
-fixes, security updates, possible npm updates, documentation updates, and
-certain performance improvements that can be demonstrated to not break existing
-applications. Semver-minor changes are only permitted if required for bug fixes
-and then only on a case-by-case basis with LTS WG and possibly Technical
-Steering Committee (TSC) review. Semver-major changes are permitted only if
-required for security-related fixes.
-
-Once a Current branch moves into Maintenance mode, only **critical** bugs,
-**critical** security fixes, and documentation updates will be permitted.
-
-#### Landing semver-minor commits in LTS
-
-The default policy is to not land semver-minor or higher commits in any LTS
-branch. However, the LTS WG or TSC can evaluate any individual semver-minor
-commit and decide whether a special exception ought to be made. It is
-expected that such exceptions would be evaluated, in part, on the scope
-and impact of the changes on the code, the risk to ecosystem stability
-incurred by accepting the change, and the expected benefit that landing the
-commit will have for the ecosystem.
-
-Any Collaborator who feels a semver-minor commit should be landed in an LTS
-branch should attach the `lts-agenda` label to the pull request. The LTS WG
-will discuss the issue and, if necessary, will escalate the issue up to the
-TSC for further discussion.
+Long Term Support (LTS) guarantees 30-month support cycles for specific Node.js
+versions. You can find more information
+[in the full release plan](https://github.com/nodejs/Release#release-plan). Once
+a branch enters LTS, the release plan limits the types of changes permitted in
+the branch.
 
 #### How are LTS Branches Managed?
 
-There are multiple LTS branches, e.g. `v10.x` and `v8.x`. Each of these is
-paired with a staging branch: `v10.x-staging` and `v8.x-staging`.
+Each LTS release has a corresponding branch (v10.x, v8.x, etc.). Each also has a
+corresponding staging branch (v10.x-staging, v8.x-staging, etc.).
 
-As commits land on the master branch, they are cherry-picked back to each
-staging branch as appropriate. If the commit applies only to the LTS branch, the
-PR must be opened against the *staging* branch. Commits are selectively
-pulled from the staging branch into the LTS branch only when a release is
-being prepared and may be pulled into the LTS branch in a different order
-than they were landed in staging.
+Commits that land on master are cherry-picked to each staging branch as
+appropriate. If a change applies only to the LTS branch, open the PR against the
+*staging* branch. Commits from the staging branch land on the LTS branch only
+when a release is being prepared. They may land on the LTS branch in a different
+order than they were in staging.
 
-Only the members of the @nodejs/backporters team should land commits onto
-LTS staging branches.
+Only members of @nodejs/backporters should land commits onto LTS staging
+branches.
 
 #### How can I help?
 

CPP_STYLE_GUIDE.md

@@ -13,7 +13,7 @@
   * [CamelCase for methods, functions, and classes](#camelcase-for-methods-functions-and-classes)
   * [snake\_case for local variables and parameters](#snake_case-for-local-variables-and-parameters)
   * [snake\_case\_ for private class fields](#snake_case_-for-private-class-fields)
-  * [snake\_case\_ for C-like structs](#snake_case_-for-c-like-structs)
+  * [snake\_case for C-like structs](#snake_case-for-c-like-structs)
   * [Space after `template`](#space-after-template)
 * [Memory Management](#memory-management)
   * [Memory allocation](#memory-allocation)
@@ -169,7 +169,7 @@ class Foo {
 };
 ```
 
-### snake\_case\_ for C-like structs
+### snake\_case for C-like structs
 For plain C-like structs snake_case can be used.
 
 ```c++

LICENSE

@@ -118,8 +118,8 @@ The externally maintained libraries used by Node.js are:
   """
     COPYRIGHT AND PERMISSION NOTICE (ICU 58 and later)
 
-    Copyright © 1991-2018 Unicode, Inc. All rights reserved.
-    Distributed under the Terms of Use in http://www.unicode.org/copyright.html.
+    Copyright © 1991-2019 Unicode, Inc. All rights reserved.
+    Distributed under the Terms of Use in https://www.unicode.org/copyright.html.
 
     Permission is hereby granted, free of charge, to any person obtaining
     a copy of the Unicode data files and any associated documentation
@@ -1077,7 +1077,7 @@ The externally maintained libraries used by Node.js are:
     // OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
   """
 
-- jinja2, located at tools/jinja2, is licensed as follows:
+- jinja2, located at tools/inspector_protocol/jinja2, is licensed as follows:
   """
     Copyright (c) 2009 by the Jinja Team, see AUTHORS for more details.
 
@@ -1112,7 +1112,7 @@ The externally maintained libraries used by Node.js are:
     OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
   """
 
-- markupsafe, located at tools/markupsafe, is licensed as follows:
+- markupsafe, located at tools/inspector_protocol/markupsafe, is licensed as follows:
   """
     Copyright (c) 2010 by Armin Ronacher and contributors.  See AUTHORS
     for more details.
@@ -1229,7 +1229,7 @@ The externally maintained libraries used by Node.js are:
     WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
   """
 
-- gtest, located at deps/gtest, is licensed as follows:
+- gtest, located at test/cctest/gtest, is licensed as follows:
   """
     Copyright 2008, Google Inc.
     All rights reserved.
@@ -1310,3 +1310,49 @@ The externally maintained libraries used by Node.js are:
     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
     IN THE SOFTWARE.
   """
+
+- large_pages, located at src/large_pages, is licensed as follows:
+  """
+     Copyright (C) 2018 Intel Corporation
+
+     Permission is hereby granted, free of charge, to any person obtaining a copy
+     of this software and associated documentation files (the "Software"),
+     to deal in the Software without restriction, including without limitation
+     the rights to use, copy, modify, merge, publish, distribute, sublicense,
+     and/or sell copies of the Software, and to permit persons to whom
+     the Software is furnished to do so, subject to the following conditions:
+
+     The above copyright notice and this permission notice shall be included
+     in all copies or substantial portions of the Software.
+
+     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+     OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+     FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+     THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
+     OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+     ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
+     OR OTHER DEALINGS IN THE SOFTWARE.
+  """
+
+- brotli, located at deps/brotli, is licensed as follows:
+  """
+    Copyright (c) 2009, 2010, 2013-2016 by the Brotli Authors.
+
+    Permission is hereby granted, free of charge, to any person obtaining a copy
+    of this software and associated documentation files (the "Software"), to deal
+    in the Software without restriction, including without limitation the rights
+    to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+    copies of the Software, and to permit persons to whom the Software is
+    furnished to do so, subject to the following conditions:
+
+    The above copyright notice and this permission notice shall be included in
+    all copies or substantial portions of the Software.
+
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
+    AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+    OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+    THE SOFTWARE.
+  """