Merge remote-tracking branch 'nodejs/master'

Merge 9091ccd of nodejs/node `master` branch into nodejs/node-chakracore

PR-URL: #35
Reviewed-By: Jianchun Xu <Jianchun.Xu@microsoft.com>

.eslintrc

@@ -5,6 +5,7 @@ env:
 rules:
   # Possible Errors
   # https://github.com/eslint/eslint/tree/master/docs/rules#possible-errors
+  comma-dangle: [2, "only-multiline"]
   no-control-regex: 2
   no-debugger: 2
   no-dupe-args: 2
@@ -30,6 +31,7 @@ rules:
   no-fallthrough: 2
   no-octal: 2
   no-redeclare: 2
+  no-unused-labels: 2
 
   # Variables
   # http://eslint.org/docs/rules/#variables
@@ -41,6 +43,7 @@ rules:
   # http://eslint.org/docs/rules/#nodejs-and-commonjs
   no-mixed-requires: 2
   no-new-require: 2
+  no-path-concat: 2
   no-restricted-modules: [2, "sys", "_linklist"]
 
   # Stylistic Issues
@@ -71,6 +74,7 @@ rules:
   no-confusing-arrow: 2
   no-const-assign: 2
   no-dupe-class-members: 2
+  no-new-symbol: 2
   no-this-before-super: 2
   prefer-const: 2
 
@@ -79,7 +83,6 @@ rules:
   strict: [2, "global"]
 
   # Custom rules in tools/eslint-rules
-  require-buffer: 2
   new-with-error: [2, "Error", "RangeError", "TypeError", "SyntaxError", "ReferenceError"]
 
 

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,14 @@
+_Thanks for wanting to report an issue you've found in Node.js. Please delete
+this text and fill in the template below. If unsure about something, just do as
+best as you're able._
+
+_Note that it will be much easier for us to fix the issue if a test case that
+reproduces the problem is provided. Ideally this test case should not have any
+external dependencies. We understand that it is not always possible to reduce
+your code to a small test case, but we would appreciate to have as much data as
+possible. Thank you!_
+
+* **Version**: _output of `node -v`_
+* **Platform**: _either `uname -a` output, or if Windows, version and 32-bit or
+  64-bit_
+* **Subsystem**: _optional. if known - please specify affected core module name_

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,24 @@
+### Pull Request check-list
+
+_Please make sure to review and check all of these items:_
+
+- [ ] Does `make -j8 test` (UNIX) or `vcbuild test nosign` (Windows) pass with
+  this change (including linting)?
+- [ ] Is the commit message formatted according to [CONTRIBUTING.md][0]?
+- [ ] If this change fixes a bug (or a performance problem), is a regression
+  test (or a benchmark) included?
+- [ ] Is a documentation update included (if this change modifies
+  existing APIs, or introduces new ones)?
+
+_NOTE: these things are not required to open a PR and can be done
+afterwards / while the PR is open._
+
+### Affected core subsystem(s)
+
+_Please provide affected core subsystem(s) (like buffer, cluster, crypto, etc)_
+
+[0]: https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#step-3-commit
+
+### Description of change
+
+_Please provide a description of the change here._

COLLABORATOR_GUIDE.md

@@ -4,7 +4,7 @@
 
 * [Issues and Pull Requests](#issues-and-pull-requests)
 * [Accepting Modifications](#accepting-modifications)
- - [Involving the TC](#involving-the-tc)
+ - [Involving the CTC](#involving-the-ctc)
 * [Landing Pull Requests](#landing-pull-requests)
  - [Technical HOWTO](#technical-howto)
  - [I Just Made a Mistake](#i-just-made-a-mistake)
@@ -26,7 +26,7 @@ pull requests to the Node.js project.
 Collaborators should feel free to take full responsibility for
 managing issues and pull requests they feel qualified to handle, as
 long as this is done while being mindful of these guidelines, the
-opinions of other Collaborators and guidance of the TC.
+opinions of other Collaborators and guidance of the CTC.
 
 Collaborators may **close** any issue or pull request they believe is
 not relevant for the future of the Node.js project. Where this is
@@ -40,7 +40,7 @@ necessary.
 
 All modifications to the Node.js code and documentation should be
 performed via GitHub pull requests, including modifications by
-Collaborators and TC members.
+Collaborators and CTC members.
 
 All pull requests must be reviewed and accepted by a Collaborator with
 sufficient expertise who is able to take full responsibility for the
@@ -64,7 +64,7 @@ Where there is no disagreement amongst Collaborators, a pull request
 may be landed given appropriate review. Where there is discussion
 amongst Collaborators, consensus should be sought if possible. The
 lack of consensus may indicate the need to elevate discussion to the
-TC for resolution (see below).
+CTC for resolution (see below).
 
 All bugfixes require a test case which demonstrates the defect. The
 test should *fail* before the change, and *pass* after the change.
@@ -73,18 +73,18 @@ All pull requests that modify executable code should be subjected to
 continuous integration tests on the
 [project CI server](https://ci.nodejs.org/).
 
-### Involving the TC
+### Involving the CTC
 
-Collaborators may opt to elevate pull requests or issues to the TC for
-discussion by assigning the ***tc-agenda*** tag. This should be done
+Collaborators may opt to elevate pull requests or issues to the CTC for
+discussion by assigning the ***ctc-agenda*** tag. This should be done
 where a pull request:
 
 - has a significant impact on the codebase,
 - is inherently controversial; or
 - has failed to reach consensus amongst the Collaborators who are
   actively participating in the discussion.
 
-The TC should serve as the final arbiter where required.
+The CTC should serve as the final arbiter where required.
 
 ## Landing Pull Requests
 

GOVERNANCE.md

@@ -1,11 +1,11 @@
 # Node.js Project Governance
 
-## Technical Committee
+## Core Technical Committee
 
-The Node.js project is jointly governed by a Technical Steering Committee (TSC)
+The Node.js project is jointly governed by a Core Technical Committee (CTC)
 which is responsible for high-level guidance of the project.
 
-The TSC has final authority over this project including:
+The CTC has final authority over this project including:
 
 * Technical direction
 * Project governance and process (including this policy)
@@ -14,28 +14,28 @@ The TSC has final authority over this project including:
 * Conduct guidelines
 * Maintaining the list of additional Collaborators
 
-Initial membership invitations to the TSC were given to individuals who
+Initial membership invitations to the CTC were given to individuals who
 had been active contributors to Node.js, and who have significant
 experience with the management of the Node.js project. Membership is
 expected to evolve over time according to the needs of the project.
 
-For the current list of TSC members, see the project
+For the current list of CTC members, see the project
 [README.md](./README.md#current-project-team-members).
 
 ## Collaborators
 
 The [nodejs/node](https://github.com/nodejs/node) GitHub repository is
-maintained by the TC and additional Collaborators who are added by the
-TC on an ongoing basis.
+maintained by the CTC and additional Collaborators who are added by the
+CTC on an ongoing basis.
 
 Individuals making significant and valuable contributions are made
 Collaborators and given commit-access to the project. These
-individuals are identified by the TC and their addition as
-Collaborators is discussed during the weekly TC meeting.
+individuals are identified by the CTC and their addition as
+Collaborators is discussed during the weekly CTC meeting.
 
 _Note:_ If you make a significant contribution and are not considered
-for commit-access, log an issue or contact a TC member directly and it
-will be brought up in the next TC meeting.
+for commit-access, log an issue or contact a CTC member directly and it
+will be brought up in the next CTC meeting.
 
 Modifications of the contents of the nodejs/node repository are made on
 a collaborative basis. Anybody with a GitHub account may propose a
@@ -51,8 +51,8 @@ on the consensus model used for governance.
 
 Collaborators may opt to elevate significant or controversial
 modifications, or modifications that have not found consensus to the
-TC for discussion by assigning the ***tc-agenda*** tag to a pull
-request or issue. The TC should serve as the final arbiter where
+CTC for discussion by assigning the ***ctc-agenda*** tag to a pull
+request or issue. The CTC should serve as the final arbiter where
 required.
 
 For the current list of Collaborators, see the project
@@ -61,39 +61,39 @@ For the current list of Collaborators, see the project
 A guide for Collaborators is maintained in
 [COLLABORATOR_GUIDE.md](./COLLABORATOR_GUIDE.md).
 
-## TC Membership
+## CTC Membership
 
-TC seats are not time-limited.  There is no fixed size of the TC.
+CTC seats are not time-limited.  There is no fixed size of the CTC.
 However, the expected target is between 6 and 12, to ensure adequate
 coverage of important areas of expertise, balanced with the ability to
 make decisions efficiently.
 
-There is no specific set of requirements or qualifications for TC
+There is no specific set of requirements or qualifications for CTC
 membership beyond these rules.
 
-The TC may add additional members to the TC by a standard TC motion.
+The CTC may add additional members to the CTC by a standard CTC motion.
 
-A TC member may be removed from the TC by voluntary resignation, or by
-a standard TC motion.
+A CTC member may be removed from the CTC by voluntary resignation, or by
+a standard CTC motion.
 
-Changes to TC membership should be posted in the agenda, and may be
-suggested as any other agenda item (see "TC Meetings" below).
+Changes to CTC membership should be posted in the agenda, and may be
+suggested as any other agenda item (see "CTC Meetings" below).
 
-No more than 1/3 of the TC members may be affiliated with the same
-employer.  If removal or resignation of a TC member, or a change of
-employment by a TC member, creates a situation where more than 1/3 of
-the TC membership shares an employer, then the situation must be
-immediately remedied by the resignation or removal of one or more TC
+No more than 1/3 of the CTC members may be affiliated with the same
+employer.  If removal or resignation of a CTC member, or a change of
+employment by a CTC member, creates a situation where more than 1/3 of
+the CTC membership shares an employer, then the situation must be
+immediately remedied by the resignation or removal of one or more CTC
 members affiliated with the over-represented employer(s).
 
-## TC Meetings
+## CTC Meetings
 
-The TC meets weekly on a Google Hangout On Air. The meeting is run by
-a designated moderator approved by the TC. Each meeting should be
+The CTC meets weekly on a Google Hangout On Air. The meeting is run by
+a designated moderator approved by the CTC. Each meeting should be
 published to YouTube.
 
-Items are added to the TC agenda which are considered contentious or
-are modifications of governance, contribution policy, TC membership,
+Items are added to the CTC agenda which are considered contentious or
+are modifications of governance, contribution policy, CTC membership,
 or release process.
 
 The intention of the agenda is not to approve or review all patches.
@@ -102,34 +102,31 @@ group of Collaborators.
 
 Any community member or contributor can ask that something be added to
 the next meeting's agenda by logging a GitHub Issue. Any Collaborator,
-TC member or the moderator can add the item to the agenda by adding
-the ***tc-agenda*** tag to the issue.
+CTC member or the moderator can add the item to the agenda by adding
+the ***ctc-agenda*** tag to the issue.
 
-Prior to each TC meeting, the moderator will share the Agenda with
-members of the TC. TC members can add any items they like to the
-agenda at the beginning of each meeting. The moderator and the TC
+Prior to each CTC meeting, the moderator will share the Agenda with
+members of the CTC. CTC members can add any items they like to the
+agenda at the beginning of each meeting. The moderator and the CTC
 cannot veto or remove items.
 
-The TC may invite persons or representatives from certain projects to
-participate in a non-voting capacity. These invitees currently are:
-
-* A representative from [build](https://github.com/node-forward/build)
-  chosen by that project.
+The CTC may invite persons or representatives from certain projects to
+participate in a non-voting capacity.
 
 The moderator is responsible for summarizing the discussion of each
 agenda item and sending it as a pull request after the meeting.
 
 ## Consensus Seeking Process
 
-The TC follows a
+The CTC follows a
 [Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making)
 decision making model.
 
 When an agenda item has appeared to reach a consensus, the moderator
 will ask "Does anyone object?" as a final call for dissent from the
 consensus.
 
-If an agenda item cannot reach a consensus, a TC member can call for
+If an agenda item cannot reach a consensus, a CTC member can call for
 either a closing vote or a vote to table the issue to the next
-meeting. The call for a vote must be approved by a majority of the TC
+meeting. The call for a vote must be approved by a majority of the CTC
 or else the discussion will continue. Simple majority wins.

Makefile

@@ -21,8 +21,9 @@ ifdef ENABLE_V8_TAP
   TAP_V8_BENCHMARKS := --junitout v8-benchmarks-tap.xml
 endif
 
+V8_TEST_OPTIONS = $(V8_EXTRA_TEST_OPTIONS)
 ifdef DISABLE_V8_I18N
-  V8_TEST_NO_I18N := --noi18n
+  V8_TEST_OPTIONS += --noi18n
   V8_BUILD_OPTIONS += i18nsupport=off
 endif
 
@@ -111,9 +112,9 @@ v8:
 	$(MAKE) -C deps/v8 $(V8_ARCH) $(V8_BUILD_OPTIONS)
 
 test: | cctest  # Depends on 'all'.
-	$(PYTHON) tools/test.py --mode=release message parallel sequential -J
 	$(MAKE) jslint
 	$(MAKE) cpplint
+	$(PYTHON) tools/test.py --mode=release message parallel sequential -J
 
 test-parallel: all
 	$(PYTHON) tools/test.py --mode=release parallel -J
@@ -210,7 +211,7 @@ test-timers-clean:
 test-v8:
 	# note: performs full test unless QUICKCHECK is specified
 	deps/v8/tools/run-tests.py --arch=$(V8_ARCH) \
-        --mode=$(BUILDTYPE_LOWER) $(V8_TEST_NO_I18N) $(QUICKCHECK_ARG) \
+        --mode=$(BUILDTYPE_LOWER) $(V8_TEST_OPTIONS) $(QUICKCHECK_ARG) \
         --no-presubmit \
         --shell-dir=$(PWD)/deps/v8/out/$(V8_ARCH).$(BUILDTYPE_LOWER) \
 	 $(TAP_V8)
@@ -578,7 +579,7 @@ bench-idle:
 
 jslint:
 	$(NODE) tools/eslint/bin/eslint.js lib src test tools/doc tools/eslint-rules \
-		--rulesdir tools/eslint-rules --quiet
+		--rulesdir tools/eslint-rules
 
 CPPLINT_EXCLUDE ?=
 CPPLINT_EXCLUDE += src/node_lttng.cc

ROADMAP.md

@@ -11,9 +11,9 @@ Node.js does not remove stdlib JS API.
 Shipping with current and well supported dependencies is the best way to ensure long term stability of the platform. When those dependencies are no longer maintained Node.js will take on their continued maintenance as part of our [Long Term Support policy](#long-term-support).
 
 Node.js will continue to adopt new V8 releases.
-* When V8 ships a breaking change to their C++ API that can be handled by [`nan`](https://github.com/rvagg/nan)
+* When V8 ships a breaking change to their C++ API that can be handled by [`nan`](https://github.com/nodejs/nan)
 the *minor* version of Node.js will be increased.
-* When V8 ships a breaking change to their C++ API that can NOT be handled by [`nan`](https://github.com/rvagg/nan)
+* When V8 ships a breaking change to their C++ API that can NOT be handled by [`nan`](https://github.com/nodejs/nan)
 the *major* version of Node.js will be increased.
 * When new features in the JavaScript language are introduced by V8 the
 *minor* version number will be increased. TC39 has stated clearly that no

WORKING_GROUPS.md

@@ -1,11 +1,11 @@
-# Node.js Working Groups
+# Node.js Core Working Groups
 
-Node.js Working Groups are autonomous projects created by the
-[Technical Steering Committee (TSC)](https://github.com/nodejs/node/blob/master/GOVERNANCE.md#technical-committee).
+Node.js Core Working Groups are autonomous projects created by the
+[Core Technical Committee (CTC)](https://github.com/nodejs/node/blob/master/GOVERNANCE.md#core-technical-committee).
 
-Working Groups can be formed at any time but must be ratified by the TSC.
+Working Groups can be formed at any time but must be ratified by the CTC.
 Once formed the work defined in the Working Group charter is the
-responsibility of the WG rather than the TSC.
+responsibility of the WG rather than the CTC.
 
 It is important that Working Groups are not formed pre-maturely. Working
 Groups are not formed to *begin* a set of tasks but instead are formed
@@ -14,7 +14,7 @@ think it would benefit from being done as an autonomous project.
 
 If the work defined in a Working Group charter is completed the Working
 Group should be dissolved and the responsibility for governance absorbed
-back in to the TSC.
+back in to the CTC.
 
 ## Current Working Groups
 
@@ -229,9 +229,9 @@ Their responsibilities are:
 * Maintaining the [addon-examples](https://github.com/nodejs/node-addon-examples)
   GitHub repository, including code, issues and documentation.
 * Maintaining the C++ Addon API within the Node.js project, in subordination to
-  the Node.js TSC.
+  the Node.js CTC.
 * Maintaining the Addon documentation within the Node.js project, in
-  subordination to the Node.js TSC.
+  subordination to the Node.js CTC.
 * Maintaining the _nan_ package in npm, releasing new versions as appropriate.
 * Messaging about the future of the Node.js and NAN interface to give the
   community advance notice of changes.

benchmark/arrays/var-int.js

@@ -1,3 +1,4 @@
+'use strict';
 var common = require('../common.js');
 var bench = common.createBenchmark(main, {
   type: 'Array Buffer Int8Array Uint8Array Int16Array Uint16Array Int32Array Uint32Array Float32Array Float64Array'.split(' '),