Revert "src: remove unused function"

.eslintrc.yaml

@@ -43,6 +43,7 @@ rules:
   # Best Practices
   # http://eslint.org/docs/rules/#best-practices
   accessor-pairs: error
+  array-callback-return: error
   dot-location: [error, property]
   eqeqeq: [error, smart]
   no-fallthrough: error

.gitignore

@@ -59,6 +59,7 @@ _UpgradeReport_Files/
 ipch/
 *.sdf
 *.opensdf
+*.VC.db
 *.VC.opendb
 .vs/
 .vscode/

.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

COLLABORATOR_GUIDE.md

@@ -4,7 +4,7 @@
 
 * [Issues and Pull Requests](#issues-and-pull-requests)
   - [Managing Issues and Pull Requests](#managing-issues-and-pull-requests)
-  - [Welcoming First-Time Contributiors](#welcoming-first-time-contributiors)
+  - [Welcoming First-Time Contributors](#welcoming-first-time-contributors)
   - [Closing Issues and Pull Requests](#closing-issues-and-pull-requests)
 * [Accepting Modifications](#accepting-modifications)
   - [Code Reviews and Consensus Seeking](#code-reviews-and-consensus-seeking)
@@ -33,7 +33,7 @@
     - [How is an LTS release cut?](#how-is-an-lts-release-cut)
 
 This document contains information for Collaborators of the Node.js
-project regarding maintaining the code, documentation, and issues.
+project regarding managing the project's code, documentation, and issue tracker.
 
 Collaborators should be familiar with the guidelines for new
 contributors in [CONTRIBUTING.md](./CONTRIBUTING.md) and also
@@ -52,11 +52,11 @@ may also notify other qualified parties for more input on an issue
 or a pull request.
 [See "Who to CC in issues"](./doc/onboarding-extras.md#who-to-cc-in-issues)
 
-### Welcoming First-Time Contributiors
+### Welcoming First-Time Contributors
 
 Courtesy should always be shown to individuals submitting issues and pull
 requests to the Node.js project. Be welcoming to first-time contributors,
-identified by the GitHub ![badge](./doc/first_timer_badge.png) badge.
+identified by the GitHub ![First-time contributor](./doc/first_timer_badge.png) badge.
 
 For first-time contributors, check if the commit author is the same as the
 pull request author, and ask if they have configured their git
@@ -116,6 +116,11 @@ oppose the PR, it can be landed. Where there is disagreement among TSC members
 or objections from one or more Collaborators, `semver-major` pull requests
 should be put on the TSC meeting agenda.
 
+#### Helpful resources
+
+* How to respectfully and usefully review code, part [one](https://mtlynch.io/human-code-reviews-1/) and [two](https://mtlynch.io/human-code-reviews-2/)
+* [How to write a positive code review](https://css-tricks.com/code-review-etiquette/)
+
 ### Waiting for Approvals
 
 Before landing pull requests, sufficient time should be left for input
@@ -142,6 +147,7 @@ test should *fail* before the change, and *pass* after the change.
 All pull requests that modify executable code should be subjected to
 continuous integration tests on the
 [project CI server](https://ci.nodejs.org/).
+The pull request should have a CI status indicator if possible.
 
 #### Useful CI Jobs
 
@@ -200,11 +206,10 @@ Node.js API are internal:
 - Any native C/C++ APIs/ABIs exported by the Node.js `*.h` header files that
   are hidden behind the `NODE_WANT_INTERNALS` flag are internal.
 
-Exception to each of these points can be made if use or behavior of a given
-internal API can be demonstrated to be sufficiently relied upon by the Node.js
-ecosystem such that any changes would cause too much breakage. The threshold
-for what qualifies as too much breakage is to be decided on a case-by-case
-basis by the TSC.
+Exceptions can be made if use or behavior of a given internal API can be
+demonstrated to be sufficiently relied upon by the Node.js ecosystem such that
+any changes would cause too much breakage. The threshold for what qualifies as
+too much breakage is to be decided on a case-by-case basis by the TSC.
 
 If it is determined that a currently undocumented object, property, method,
 argument, or event *should* be documented, then a pull request adding the
@@ -243,14 +248,14 @@ properties to an options argument) are semver-minor changes.
 
 #### Breaking Changes and Deprecations
 
-With a few notable exceptions outlined below, when backwards 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 backwards incompatible way) without a deprecation.
+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.
 
-Exception to this rule is given in the following cases:
+Exceptions to this rule may be made in the following cases:
 
 * Adding or removing errors thrown or reported by a Public API;
 * Changing error messages;
@@ -351,7 +356,7 @@ recommended but not required.
 ### Deprecations
 
 _Deprecation_ refers to the identification of Public APIs that should no longer
-be used and that may be removed or modified in non-backwards compatible ways in
+be used and that may be removed or modified in backward-incompatible ways in
 a future major release of Node.js. Deprecation may be used with internal APIs if
 there is expected impact on the user community.
 
@@ -491,7 +496,7 @@ Check and re-review the changes:
 $ git diff upstream/master
 ```
 
-Check number of commits and commit messages:
+Check the number of commits and commit messages:
 
 ```text
 $ git log upstream/master...master
@@ -652,7 +657,7 @@ commit final.
 #### 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.
+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).
@@ -665,7 +670,7 @@ 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.
+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.

CONTRIBUTING.md

@@ -1,17 +1,15 @@
 # Contributing to Node.js
 
-Contributions to Node.js may come in many forms. Some contribute code changes,
-others contribute docs, others help answer questions from users, help keep the
-infrastructure running, or seek out ways of advocating for Node.js users of all
-types.
+Contributions to Node.js include code, documentation, answering user questions,
+running the project's infrastructure, and advocating for all types of Node.js
+users.
 
 The Node.js project welcomes all contributions from anyone willing to work in
-good faith both with other contributors and with the community. No contribution
-is too small and all contributions are valued.
+good faith with other contributors and the community. No contribution is too
+small and all contributions are valued.
 
-This guide details the basic steps for getting started contributing to the
-Node.js project's core `nodejs/node` GitHub Repository and describes what to
-expect throughout each step of the process.
+This guide explains the process for contributing to the Node.js project's core
+`nodejs/node` GitHub Repository and describes what to expect at each step.
 
 * [Code of Conduct](#code-of-conduct)
   * [Bad Actors](#bad-actors)
@@ -201,9 +199,8 @@ functional guidelines of the Node.js project.
 
 ## Pull Requests
 
-Pull Requests are the way in which concrete changes are made to the code,
-documentation, dependencies, and tools contained with the `nodejs/node`
-repository.
+Pull Requests are the way concrete changes are made to the code, documentation,
+dependencies, and tools contained in the `nodejs/node` repository.
 
 There are two fundamental components of the Pull Request process: one concrete
 and technical, and one more process oriented. The concrete and technical
@@ -605,12 +602,11 @@ your name on it. Congratulations and thanks for your contribution!
 All Node.js contributors who choose to review and provide feedback on Pull
 Requests have a responsibility to both the project and the individual making the
 contribution. Reviews and feedback must be helpful, insightful, and geared
-towards improving the contribution as opposed to simply blocking it or
-stopping it. If there are reasons why you feel the PR should not land, explain
-what those are. Do not expect to be able to block a Pull Request from advancing
-simply because you say "No" without giving an explanation. It is also important
-to be open to having your mind changed, and to being open to working with the
-contributor to make the Pull Request better.
+towards improving the contribution as opposed to simply blocking it. If there
+are reasons why you feel the PR should not land, explain what those are. Do not
+expect to be able to block a Pull Request from advancing simply because you say
+"No" without giving an explanation. Be open to having your mind changed. Be open
+to working with the contributor to make the Pull Request better.
 
 Reviews that are dismissive or disrespectful of the contributor or any other
 reviewers are strictly counter to the [Code of Conduct][].

CPP_STYLE_GUIDE.md

@@ -4,6 +4,7 @@
 
 * [Formatting](#formatting)
   * [Left-leaning (C++ style) asterisks for pointer declarations](#left-leaning-c-style-asterisks-for-pointer-declarations)
+  * [C++ style comments](#c-style-comments)
   * [2 spaces of indentation for blocks or bodies of conditionals](#2-spaces-of-indentation-for-blocks-or-bodies-of-conditionals)
   * [4 spaces of indentation for statement continuations](#4-spaces-of-indentation-for-statement-continuations)
   * [Align function arguments vertically](#align-function-arguments-vertically)
@@ -33,6 +34,26 @@ these rules:
 
 `char* buffer;` instead of `char *buffer;`
 
+## C++ style comments
+
+Use C++ style comments (`//`) for both single-line and multi-line comments.
+Comments should also start with uppercase and finish with a dot.
+
+Examples:
+
+```c++
+// A single-line comment.
+
+// Multi-line comments
+// should also use C++
+// style comments.
+```
+
+The codebase may contain old C style comments (`/* */`) from before this was the
+preferred style. Feel free to update old comments to the preferred style when
+working on code in the immediate vicinity or when changing/improving those
+comments.
+
 ## 2 spaces of indentation for blocks or bodies of conditionals
 
 ```c++