v8.9.2 proposal

BUILDING.md

@@ -199,9 +199,11 @@ Prerequisites:
   * [Visual Studio 2015 Update 3](https://www.visualstudio.com/), all editions
     including the Community edition (remember to select
     "Common Tools for Visual C++ 2015" feature during installation).
-  * [Visual Studio 2017](https://www.visualstudio.com/downloads/), any edition (including the Build Tools SKU).
-    **Required Components:** "MSbuild", "VC++ 2017 v141 toolset" and at least one of the Windows SDKs.
-    *Note*: For "Windows 10 SDK (10.0.15063.0)" only the "Desktop C++ x86 and x64" flavor is required.
+  * The "Desktop development with C++" workload from
+    [Visual Studio 2017](https://www.visualstudio.com/downloads/) or the
+    "Visual C++ build tools" workload from the
+    [Build Tools](https://www.visualstudio.com/downloads/#build-tools-for-visual-studio-2017),
+    with the default optional components.
 * Basic Unix tools required for some tests,
   [Git for Windows](http://git-scm.com/download/win) includes Git Bash
   and tools which can be included in the global `PATH`.

CHANGELOG.md

@@ -27,7 +27,8 @@ release.
 </tr>
 <tr>
     <td valign="top">
-<b><a href="doc/changelogs/CHANGELOG_V8.md#8.9.1">8.9.1</a></b><br/>
+<b><a href="doc/changelogs/CHANGELOG_V8.md#8.9.2">8.9.2</a></b><br/>
+<a href="doc/changelogs/CHANGELOG_V8.md#8.9.1">8.9.1</a><br/>
 <a href="doc/changelogs/CHANGELOG_V8.md#8.9.0">8.9.0</a><br/>
 <a href="doc/changelogs/CHANGELOG_V8.md#8.8.1">8.8.1</a><br/>
 <a href="doc/changelogs/CHANGELOG_V8.md#8.8.0">8.8.0</a><br/>

COLLABORATOR_GUIDE.md

@@ -371,60 +371,45 @@ The TSC should serve as the final arbiter where required.
     * If more than one author has contributed to the PR, keep the most recent
       author when squashing.
 
-Always modify the original commit message to include additional meta
-information regarding the change process:
-
-- A `PR-URL:` line that references the *full* GitHub URL of the original
-  pull request being merged so it's easy to trace a commit back to the
-  conversation that led up to that change.
-- A `Fixes: X` line, where _X_ either includes the *full* GitHub URL
-  for an issue, and/or the hash and commit message if the commit fixes
-  a bug in a previous commit. Multiple `Fixes:` lines may be added if
-  appropriate.
-- A `Refs:` line referencing a URL for any relevant background.
-- A `Reviewed-By: Name <email>` line for yourself and any
-  other Collaborators who have reviewed the change.
-  - Useful for @mentions / contact list if something goes wrong in the PR.
-  - Protects against the assumption that GitHub will be around forever.
-
 Review the commit message to ensure that it adheres to the guidelines outlined
 in the [contributing](./CONTRIBUTING.md#commit-message-guidelines) guide.
 
+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.
 
 Additionally:
 - Double check PRs to make sure the person's _full name_ and email
   address are correct before merging.
-- Except when updating dependencies, 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.
+- 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.
 
 ### Technical HOWTO
 
-Clear any `am`/`rebase` that may already be underway.
+Clear any `am`/`rebase` that may already be underway:
 
 ```text
 $ git am --abort
 $ git rebase --abort
 ```
 
-Checkout proper target branch
+Checkout proper target branch:
 
 ```text
 $ git checkout master
 ```
 
 Update the tree (assumes your repo is set up as detailed in
-[CONTRIBUTING.md](CONTRIBUTING.md#step-1-fork))
+[CONTRIBUTING.md](CONTRIBUTING.md#step-1-fork)):
 
 ```text
 $ git fetch upstream
 $ git merge --ff-only upstream/master
 ```
 
-Apply external patches
+Apply external patches:
 
 ```text
 $ curl -L https://github.com/nodejs/node/pull/xxx.patch | git am --whitespace=fix
@@ -442,21 +427,19 @@ against the original PR carefully and build/test on at least one platform
 before landing. If the 3-way merge fails, then it is most likely that a conflicting
 PR has landed since the CI run and you will have to ask the author to rebase.
 
-Check and re-review the changes
+Check and re-review the changes:
 
 ```text
 $ git diff upstream/master
 ```
 
-Check number of commits and commit messages
+Check number of commits and commit messages:
 
 ```text
 $ git log upstream/master...master
 ```
 
-If there are multiple commits that relate to the same feature or
-one with a feature and separate with a test for that feature,
-you'll need to use `squash` or `fixup`:
+Squash commits and add metadata:
 
 ```text
 $ git rebase -i upstream/master
@@ -512,9 +495,28 @@ Save the file and close the editor. You'll be asked to enter a new
 commit message for that commit. This is a good moment to fix incorrect
 commit logs, ensure that they are properly formatted, and add
 `Reviewed-By` lines.
+
 * The commit message text must conform to the
 [commit message guidelines](./CONTRIBUTING.md#commit-message-guidelines).
 
+<a name="metadata"></a>
+* Modify the original commit message to include additional metadata regarding
+  the change process. ([`node-core-utils`][] fetches the metadata for you.)
+
+  * Required: A `PR-URL:` line that references the *full* GitHub URL of the
+    original pull request being merged so it's easy to trace a commit back to
+    the conversation that led up to that change.
+  * Optional: A `Fixes: X` line, where _X_ either includes the *full* GitHub URL
+    for an issue, and/or the hash and commit message if the commit fixes
+    a bug in a previous commit. Multiple `Fixes:` lines may be added if
+    appropriate.
+  * Optional: One or more `Refs:` lines referencing a URL for any relevant
+    background.
+  * Required: A `Reviewed-By: Name <email>` line for yourself and any
+    other Collaborators who have reviewed the change.
+    * Useful for @mentions / contact list if something goes wrong in the PR.
+    * Protects against the assumption that GitHub will be around forever.
+
 Run tests (`make -j4 test` or `vcbuild test`). Even though there was a
 successful continuous integration run, other changes may have landed on master
 since then, so running the tests one last time locally is a good practice.
@@ -678,3 +680,4 @@ LTS working group and the Release team.
 [Stability Index]: doc/api/documentation.md#stability-index
 [Enhancement Proposal]: https://github.com/nodejs/node-eps
 [git-username]: https://help.github.com/articles/setting-your-username-in-git/
+[`node-core-utils`]: https://github.com/nodejs/node-core-utils

CONTRIBUTING.md

@@ -334,6 +334,14 @@ use `Refs:`.
    - `Refs: http://eslint.org/docs/rules/space-in-parens.html`
    - `Refs: https://github.com/nodejs/node/pull/3615`
 
+5. If your commit introduces a breaking change (`semver-major`), it should
+contain an explanation about the reason of the breaking change, which
+situation would trigger the breaking change and what is the exact change.
+
+Breaking changes will be listed in the wiki with the aim to make upgrading
+easier.  Please have a look at [Breaking Changes](https://github.com/nodejs/node/wiki/Breaking-changes-between-v4-LTS-and-v6-LTS)
+for the level of detail that's suitable.
+
 Sample complete commit message:
 
 ```txt
@@ -625,6 +633,7 @@ Focus first on the most significant aspects of the change:
 1. Does this change make sense for Node.js?
 2. Does this change make Node.js better, even if only incrementally?
 3. Are there clear bugs or larger scale issues that need attending to?
+4. Is the commit message readable and correct? If it contains a breaking change is it clear enough?
 
 When changes are necessary, *request* them, do not *demand* them, and do not
 assume that the submitter already knows how to add a test or run a benchmark.

CPP_STYLE_GUIDE.md

@@ -127,6 +127,21 @@ class FancyContainer {
 
 What it says in the title.
 
+## Do not include `*.h` if `*-inl.h` has already been included
+
+Do
+
+```cpp
+#include "util-inl.h"  // already includes util.h
+```
+
+instead of
+
+```cpp
+#include "util.h"
+#include "util-inl.h"
+```
+
 ## Avoid throwing JavaScript errors in nested C++ methods
 
 If you need to throw JavaScript errors from a C++ binding method, try to do it

LICENSE

@@ -1146,3 +1146,26 @@ The externally maintained libraries used by Node.js are:
     OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
     THE SOFTWARE.
   """
+
+- node-inspect, located at deps/node-inspect, is licensed as follows:
+  """
+    Copyright Node.js contributors. All rights reserved.
+
+    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.
+  """

Makefile

@@ -974,17 +974,41 @@ bench-ci: bench
 lint-md-clean:
 	$(RM) -r tools/remark-cli/node_modules
 	$(RM) -r tools/remark-preset-lint-node/node_modules
+	$(RM) tools/.*mdlintstamp
 
 lint-md-build:
-	if [ ! -d tools/remark-cli/node_modules ]; then \
+	@if [ ! -d tools/remark-cli/node_modules ]; then \
+		echo "Markdown linter: installing remark-cli into tools/"; \
 		cd tools/remark-cli && ../../$(NODE) ../../$(NPM) install; fi
-	if [ ! -d tools/remark-preset-lint-node/node_modules ]; then \
+	@if [ ! -d tools/remark-preset-lint-node/node_modules ]; then \
+		echo "Markdown linter: installing remark-preset-lint-node into tools/"; \
 		cd tools/remark-preset-lint-node && ../../$(NODE) ../../$(NPM) install; fi
 
-lint-md: lint-md-build
-	@echo "Running Markdown linter..."
-	$(NODE) tools/remark-cli/cli.js -q -f \
-		./*.md doc src lib benchmark tools/doc/ tools/icu/
+ifneq ("","$(wildcard tools/remark-cli/node_modules/)")
+LINT_MD_TARGETS = src lib benchmark tools/doc tools/icu
+LINT_MD_ROOT_DOCS := $(wildcard *.md)
+LINT_MD_FILES := $(shell find $(LINT_MD_TARGETS) -type f \
+  -not -path '*node_modules*' -name '*.md') $(LINT_MD_ROOT_DOCS)
+LINT_DOC_MD_FILES = $(shell ls doc/**/*.md)
+
+tools/.docmdlintstamp: $(LINT_DOC_MD_FILES)
+	@echo "Running Markdown linter on docs..."
+	@$(NODE) tools/remark-cli/cli.js -q -f $(LINT_DOC_MD_FILES)
+	@touch $@
+
+tools/.miscmdlintstamp: $(LINT_MD_FILES)
+	@echo "Running Markdown linter on misc docs..."
+	@$(NODE) tools/remark-cli/cli.js -q -f $(LINT_MD_FILES)
+	@touch $@
+
+tools/.mdlintstamp: tools/.miscmdlintstamp tools/.docmdlintstamp
+
+lint-md: | tools/.mdlintstamp
+else
+lint-md:
+	@echo "The markdown linter is not installed."
+	@echo "To install (requires internet access) run: $ make lint-md-build"
+endif
 
 LINT_JS_TARGETS = benchmark doc lib test tools
 LINT_JS_CMD = tools/eslint/bin/eslint.js --cache \
@@ -1046,10 +1070,13 @@ LINT_CPP_FILES = $(filter-out $(LINT_CPP_EXCLUDE), $(wildcard \
 # and the actual filename is generated so it won't match header guards
 ADDON_DOC_LINT_FLAGS=-whitespace/ending_newline,-build/header_guard
 
-lint-cpp:
+lint-cpp: tools/.cpplintstamp
+
+tools/.cpplintstamp: $(LINT_CPP_FILES)
 	@echo "Running C++ linter..."
-	@$(PYTHON) tools/cpplint.py $(LINT_CPP_FILES)
+	@$(PYTHON) tools/cpplint.py $?
 	@$(PYTHON) tools/check-imports.py
+	@touch $@
 
 lint-addon-docs: test/addons/.docbuildstamp
 	@echo "Running C++ linter on addon docs..."
@@ -1085,6 +1112,10 @@ lint:
 lint-ci: lint
 endif
 
+lint-clean:
+	$(RM) tools/.*lintstamp
+	$(RM) .eslintcache
+
 .PHONY: $(TARBALL)-headers \
   all \
   bench \
@@ -1125,6 +1156,7 @@ endif
   install-bin \
   install-includes \
   lint \
+  lint-clean \
   lint-ci \
   lint-cpp \
   lint-js \

benchmark/_http-benchmarkers.js

@@ -91,11 +91,9 @@ class TestDoubleBenchmarker {
   create(options) {
     const child = child_process.fork(this.executable, {
       silent: true,
-      env: {
-        duration: options.duration,
-        connections: options.connections,
-        path: `http://127.0.0.1:${options.port}${options.path}`
-      }
+      env: Object.assign({}, process.env, {
+        test_url: `http://127.0.0.1:${options.port}${options.path}`
+      })
     });
     return child;
   }

benchmark/_test-double-benchmarker.js

@@ -2,6 +2,6 @@
 
 const http = require('http');
 
-http.get(process.env.path, function() {
+http.get(process.env.test_url, function() {
   console.log(JSON.stringify({ throughput: 1 }));
 });

deps/v8/include/v8-version.h

@@ -11,7 +11,7 @@
 #define V8_MAJOR_VERSION 6
 #define V8_MINOR_VERSION 1
 #define V8_BUILD_NUMBER 534
-#define V8_PATCH_LEVEL 47
+#define V8_PATCH_LEVEL 48
 
 // Use 1 for candidates and 0 otherwise.
 // (Boolean macro values are not supported by all preprocessors.)

deps/v8/test/message/testcfg.py

@@ -107,7 +107,7 @@ def IsFailureOutput(self, testcase):
         expected_lines, actual_lines, fillvalue=''):
       pattern = re.escape(expected.rstrip() % env)
       pattern = pattern.replace("\\*", ".*")
-      pattern = pattern.replace("\\{NUMBER\\}", "\d(?:\.\d*)?")
+      pattern = pattern.replace("\\{NUMBER\\}", "\d+(?:\.\d*)?")
       pattern = "^%s$" % pattern
       if not re.match(pattern, actual):
         return True

doc/api/assert.md

@@ -299,7 +299,7 @@ assert.fail(1, 2, 'whoops', '>');
 // AssertionError [ERR_ASSERTION]: whoops
 ```
 
-*Note*: Is the last two cases `actual`, `expected`, and `operator` have no
+*Note*: In the last two cases `actual`, `expected`, and `operator` have no
 influence on the error message.
 
 ```js