Consider the following test code:

var esprima = require('./esprima');
var code = '({ set width(w) {} })';
var tree = esprima.parse(code, { loc: true });
console.log(tree.body[0].expression.properties[0].key.loc.start.column);
console.log(tree.body[0].expression.properties[0].value.loc.start.column);
console.log(tree.body[0].expression.properties[0].value.params[0].loc.start.column);

The current master branch produced the following output:

7
16
13

This is because the key of Property node looks like:

{ loc: { start: { line: 1, column: 7 }, end: { line: 1, column: 12 } },
  type: 'Identifier',
  name: 'width' }

and the value of Property node:

{ loc: { start: { line: 1, column: 16 }, end: { line: 1, column: 18 } },
  type: 'FunctionExpression',
  id: null,
  params: [ { loc: [Object], type: 'Identifier', name: 'w' } ],
  defaults: [],
  body: 
   { loc: { start: [Object], end: [Object] },
     type: 'BlockStatement',
     body: [] },
  rest: null,
  generator: false,
  expression: false }

with its first parameter as:

{ loc: { start: { line: 1, column: 13 }, end: { line: 1, column: 14 } },
  type: 'Identifier',
  name: 'w' }

This is different than the result of SpiderMonkey (Reflect.parse instead of esprima.parse):

7
7
13

For the analysis, this is how the Property looks like:

{
  "loc": {
    "start": {
      "line": 1,
      "column": 7
    },
    "end": {
      "line": 1,
      "column": 18
    },
    "source": null
  },
  "type": "Property",
  "key": {
    "loc": {
      "start": {
        "line": 1,
        "column": 7
      },
      "end": {
        "line": 1,
        "column": 12
      },
      "source": null
    },
    "type": "Identifier",
    "name": "width"
  },
  "value": {
    "loc": {
      "start": {
        "line": 1,
        "column": 7
      },
      "end": {
        "line": 1,
        "column": 18
      },
      "source": null
    },
    "type": "FunctionExpression",
    "id": null,
    "params": [
      {
        "loc": {
          "start": {
            "line": 1,
            "column": 13
          },
          "end": {
            "line": 1,
            "column": 14
          },
          "source": null
        },
        "type": "Identifier",
        "name": "w"
      }
    ],
    "defaults": [],
    "body": {
      "loc": {
        "start": {
          "line": 1,
          "column": 16
        },
        "end": {
          "line": 1,
          "column": 17
        },
        "source": null
      },
      "type": "BlockStatement",
      "body": []
    },
    "rest": null,
    "generator": false,
    "expression": false
  },
  "kind": "set",
  "method": false,
  "shorthand": false
}

The result from SpiderMonkey is more sensible. Note how the value of the Property node starts as the same place (column: 7) as the key.

Code:

var obj = {
  myfunc() { return null; }
}

myfunc node doesn't have truthy shorthand property.

{ type: 'Property',
  key:
   { type: 'Identifier',
     name: 'myfunc',
     range: [ 16, 22 ],
     loc: { start: [Object], end: [Object] },
     parentNode: [Circular],
     parentCollection: [ undefined ] },
  value:
   { type: 'FunctionExpression',
     id: null,
     params: [],
     defaults: [],
     body: { ... }, ... },
  kind: 'init',
  method: true,
  shorthand: false, // !!! here it is
  computed: false,
  parentNode: ...

Ref jscs-dev/node-jscs#1013

Syntax:

• imports:

ImportDeclaration :
  import ImportClause FromClause ;
  import ModuleSpecifier ;
ImportClause :
  ImportedDefaultBinding
  NameSpaceImport
  NamedImports
  ImportedDefaultBinding , NameSpaceImport
  ImportedDefaultBinding , NamedImports
ImportedDefaultBinding :
  ImportedBinding
NameSpaceImport :
  * as ImportedBinding
NamedImports :
  { }
  { ImportsList }
  { ImportsList , }
FromClause :
  from ModuleSpecifier
ImportsList :
  ImportSpecifier
  ImportsList , ImportSpecifier
ImportSpecifier :
  ImportedBinding
  IdentifierName as ImportedBinding
ModuleSpecifier :
  StringLiteral
ImportedBinding :
  BindingIdentifier

• exports:

ExportDeclaration :
  export * FromClause ;
  export ExportClause FromClause ;
  export ExportClause ;
  export VariableStatement
  export Declaration
  export default HoistableDeclaration[Default]
  export default ClassDeclaration[Default]
  export default [lookahead ∉ {function, class}] AssignmentExpression[In] ;
ExportClause :
  { }
  { ExportsList }
  { ExportsList , }
ExportsList :
  ExportSpecifier
  ExportsList , ExportSpecifier
ExportSpecifier :
  IdentifierName
  IdentifierName as IdentifierName

Spec:

• imports: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-imports
• exports: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports

Remaining Tasks:

• Land the Classes feature
• Review and Test Token Generation
• Review Error Messages
• Fix #311
• Address estree/estree#11
• Address https://github.com/estree/estree/pulls/38
• Address https://github.com/estree/estree/pulls/39
• Fix #1077
• Fix #1087
• Fix #1088

For example, the harmony branch has tests for es6 that doesn't include token and ranges. That fact has already hidden the fact that both template literals and modules had nasty token bugs.

Once the CLA checker is working well, we should add it to this repo. @scottgonzalez, your call on that.

In order to land modules, we must:

• Land the Classes feature
• Review and Test Token Generation
• Review Error Messages
• Fix #311

The espree fork may land it shortly as well, so we have the benefit of those dependencies as well eslint/espree#43

Ported from https://code.google.com/p/esprima/issues/detail?id=632

What steps will reproduce the problem?

1. Go here: http://esprima.googlecode.com/git-history/harmony/demo/parse.html?code=var%20foo%20%3D%20%5B%60bar%20%24%7Bbaz%7D%60%5D%3B
2. Click on the Tokens tab of the output

What is the expected output?

To see the ` token in the list of tokens.

What do you see instead?

They were not present.

What version of the product are you using? On what operating system? Which

browser?

the harmony branch

In the current syntax tree, a directive such as "use strict" will appear as ExpressionStatement. A tool that consumes the tree and needs to be aware of the strict mode will have to perform an extra step to figure out whether such an ExpressionStatement is representing a directive or not.

In this proposal, a new flag directive is added to ExpressionStatement. The value is set to true for a directive prologue.

The current state:

> esprima.parse('"use strict"').body[0]
{ type: 'ExpressionStatement',
  expression: 
   { type: 'Literal',
     value: 'use strict',
     raw: '"use strict"' } }

If this proposal is implemented, it becomes:

> esprima.parse('"use strict"').body[0]
{ type: 'ExpressionStatement',
  expression: 
   { type: 'Literal',
     value: 'use strict',
     raw: '"use strict"' },
  directive: true }

Additional resources:

• ECMAScript 5.1 Section 14.1 on Directive Prologues and the Use Strict Directive
• Previous Esprima discussion: https://code.google.com/p/esprima/issues/detail?id=330.
• SpiderMonkey issue: https://bugzilla.mozilla.org/show_bug.cgi?id=791294

When peeking for line terminators, we are calling skipComment and test if the lineNumber has changes. This is in fact unnecessary because the white space region we scanned through is a region we scanned already earlier. A flag can be added to indicate if there is a new line between index and the beginning of lookahead.

The following input cannot be parsed:

for (var i=0; i<2; i++) {
    if (i == 1)
        break
        ;
    else
        console.log(i);
}

The semicolon must be associated with the break statement. V8 and the EcmaScript specification both agree on this.

Instead, Esprima parses an empty statement after which the else causes a parse error.

Tested with Esprima 1.2.2

(Migrated from https://code.google.com/p/esprima/issues/detail?id=599, as filed by @asgerf).

Known consumers:

• ESLint
• JSCS
• Istanbul
• Escope (https://github.com/estools/escope)
• Escodegen (https://github.com/estools/escodegen)
• jstransform
• 6to5?
• recast?
• @ariya @ikarienator @jeffmo others?

Migrated from https://code.google.com/p/esprima/issues/detail?id=626.

As reported by @aslushnikov, it seems that tokenize is way too slower compared to parse.

In the benchmark:

function () {
    var syntax = esprima.parse(source, { range: true, loc: true });
    tree.push(syntax.body.length);
}

The "holding on" array tree should be cleared each run to reduce swapping overhead. gc() should be called right after it.

Syntax:

FormalParameterList[Yield,GeneratorParameter] :
  FunctionRestParameter[?Yield]
  FormalsList[?Yield, ?GeneratorParameter]
  FormalsList[?Yield, ?GeneratorParameter] , FunctionRestParameter[?Yield]
FunctionRestParameter[Yield] :
  BindingRestElement[?Yield]
BindingRestElement[Yield, GeneratorParameter] :
  [+GeneratorParameter] ... BindingIdentifier[Yield]
  [~GeneratorParameter] ... BindingIdentifier[?Yield]

Spec:

https://people.mozilla.org/~jorendorff/es6-draft.html#sec-functions-and-classes

Remaining Tasks:

• Review and Test Token Generation
• Review Error Messages
• Arrow Function Rest Parameters
• estree/estree#37

Currently the parser will accept any source-element in the final position of an export default. This is wrong as export default foo; (as just one example) should not parse since foo is not an assignment expression.

Something like karma or mocha. In fact, we should again look at what espree has done here.

From @termi in https://code.google.com/p/esprima/issues/detail?id=483

What steps will reproduce the problem?
Parse 'let test1 = ({a}) => ([a])' using esprima#harmony

What is the expected output?
AST

What do you see instead?
Error: Line 1: Unexpected token =>

Suggested Fix:
https://github.com/termi/es6-transpiler/blob/e99435f45aad8cac89c04208d1c33b4a7a57422f/lib/esprima_harmony.js#L3130#L3131

A close script tag literal, i.e. "<\/script>" is rewritten to '</script>'. This is incorrect behavior because an unescaped close script tag ends javascript execution.

The correct behavior would be to leave the backslash in the rewritten tag: '<\/script>'.

Syntax:

ArrowFunction[In, Yield] :
  ArrowParameters[?Yield] [no LineTerminator here] => ConciseBody[?In]
ArrowParameters[Yield] :
  BindingIdentifier[?Yield]
  CoverParenthesizedExpressionAndArrowParameterList[?Yield]
ConciseBody[In] :
  [lookahead ≠ { ] AssignmentExpression[?In]
  { FunctionBody }

Supplemental Syntax

When the production 
  ArrowParameters[Yield] : CoverParenthesizedExpressionAndArrowParameterList[?Yield]
is recognized the following grammar is used to refine the interpretation of
  CoverParenthesizedExpressionAndArrowParameterList :
ArrowFormalParameters[Yield, GeneratorParameter] :
  ( StrictFormalParameters[?Yield, ?GeneratorParameter] )

Spec:

https://people.mozilla.org/~jorendorff/es6-draft.html#sec-arrow-function-definitions

Remaining Tasks:

• Review and Test Token Generation
• Review Error Messages
• Land Rest Parameters #1011
• Fix #1009
• Fix #1010
• Fix #1013
• Fix #1014
• Fix #1056

What steps will reproduce the problem?

On a fresh checkout of the harmony branch:

// test.js
var esprima = require('./');

var source = [
    '({',
    '    method1(arg1) {},',
    '})'
].join('\n');

var ast = esprima.parse(source, { range: true });

console.log(ast.body[0].expression.properties[0]);
console.log(ast.body[0].expression.properties[0].value.params[0]);

$ node test.js
{ type: 'Property',
  key: { type: 'Identifier', name: 'method1', range: [ 7, 14 ] },
  value:
   { type: 'FunctionExpression',
     id: null,
     params: [ [Object] ],
     defaults: [],
     body: { type: 'BlockStatement', body: [], range: [Object] },
     rest: null,
     generator: false,
     expression: false,
     range: [ 21, 23 ] },
  kind: 'init',
  method: true,
  shorthand: false,
  computed: false,
  range: [ 7, 23 ] }
{ type: 'Identifier', name: 'arg1', range: [ 15, 19 ] }

What is the expected output?

I would expect the FunctionExpression's range to include the method's parameters as well as the body as in (arg1) {}.

It makes sense that the method's name is not included, as that is the Property's key and does not belong to the FunctionExpression.

What do you see instead?

The FunctionExpression's range includes only the body, {}, leading to a scenario in which a traversal starting at the FunctionExpression, range 21-23, would reach the parameter, whose range, 15-19, lies outside that of its parent.

(Migrated from https://code.google.com/p/esprima/issues/detail?id=625, as reported by @btmills)

Consider the following test code (parsing in tolerant mode):

require('./esprima').parse('x /* foobar', { tolerant: true })

The current master branch will thrown an exception due to the error Line 1: Unexpected token ILLEGAL.

If this feature is implemented, it will return an AST because the unclosed block comment is tolerated. The error will be still listed in the errors array.

(Migrated from https://code.google.com/p/esprima/issues/detail?id=582, as reported by @mrennie)

Investigate the use of common test runner (Karma or Venus.js, or other candidates) to run the unit tests.

The benefits:

• there is no need to write a special test runner
• execute the tests on e.g. Sauce Labs
• simplify the test fixture (individual test and expected result)

Moving the discussion from https://code.google.com/p/esprima/issues/detail?id=607

To summarize, even if the comment attachment algorithm is less ambiguous in 2.0, it was more useful in 1.2 to the library authors who were using it, and was a non BC change for eslint.

I believe that we should revert to the 1.2 behavior, and revisit the change in behavior for 3.0.0, and discuss the design decision further as a team.

@ariya @jeffmo thoughts?

To facilitate the transition of TryStatement from the old handlers to the new handler (see #1030), Esprima should produce both properties. Once all the major downstream tools have been ported to use the handler only, handlers can be safely removed in the next major version.

In the current master branch:

> require('./esprima').parse('try{}catch(e){}')
{ type: 'Program',
  body: 
   [ { type: 'TryStatement',
       block: [Object],
       guardedHandlers: [],
       handlers: [Object],
       finalizer: null } ] }

Once this transition step is implemented, it will look like:

> require('./esprima').parse('try{}catch(e){}')
{ type: 'Program',
  body: 
   [ { type: 'TryStatement',
       block: [Object],
       guardedHandlers: [],
       handlers: [Object],
       handler: [Object],
       finalizer: null } ] }

Considering our complex commit message guide, having a bot actually land patches will reduce errors in commit messages and take the burden out of landing the patch. We should investigate if existing solutions are already out there that meet our requirements as a prereq.

The TryStatement node has changed according to estree/estree#1 from

interface TryStatement <: Statement {
    type: "TryStatement";
    block: BlockStatement;
    handlers: [ CatchClause ];
    guardedHandlers: [];
    finalizer: BlockStatement | null;
}

to

interface TryStatement <: Statement {
    type: "TryStatement";
    block: BlockStatement;
    handler: CatchClause | null;
    finalizer: BlockStatement | null;
}

The differences are:

• handlers (an array of CatchClause) is changed to handler (a single CatchClause, if any)
• guardedHandlers is gone

See also https://bugzilla.mozilla.org/show_bug.cgi?id=742612.

(Migrated from https://code.google.com/p/esprima/issues/detail?id=433)

In the current syntax tree, a directive such as "use strict" will appear as ExpressionStatement. A tool that consumes the tree and needs to be aware of the strict mode will have to perform an extra step to figure out whether such an ExpressionStatement is representing a directive or not.

In this proposal, a new flag directive is added to ExpressionStatement. The value is set to true for a directive prologue.

The current state:

> esprima.parse('"use strict"').body[0]
{ type: 'ExpressionStatement',
  expression: 
   { type: 'Literal',
     value: 'use strict',
     raw: '"use strict"' } }

If this proposal is implemented, it becomes:

> esprima.parse('"use strict"').body[0]
{ type: 'ExpressionStatement',
  expression: 
   { type: 'Literal',
     value: 'use strict',
     raw: '"use strict"' },
  directive: true }

Additional resources:

• ECMAScript 5.1 Section 14.1 on Directive Prologues and the Use Strict Directive
• Previous Esprima discussion: https://code.google.com/p/esprima/issues/detail?id=330.
• SpiderMonkey issue: https://bugzilla.mozilla.org/show_bug.cgi?id=791294

This algorithm currently tests if the comment "belongs" to an AST tree if the range of the AST covers the comment. This end up giving the following result:

The comment of

a  //x

is attached to the ExpressionStatement, but the comment of

a; //x

is attached to the FunctionBody.

1. Use Esprima in Orion with an optional non-English language pack: https://wiki.eclipse.org/Orion/Internationalization#Client_-_installing_new_language_pack
2. notice that all of the parse errors are still in English

Related Orion bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=441838

(Migrated from https://code.google.com/p/esprima/issues/detail?id=578, as filed by @mrennie)

From https://code.google.com/p/esprima/issues/detail?id=633:

@jeffmo says:

As of the latest version of the spec, it is no longer statically valid to have references to 'super' in static class methods:

https://people.mozilla.org/~jorendorff/es6-draft.html#sec-class-definitions-static-semantics-early-errors

Currently esprima will parse this without issue, but it should through a syntax error.
Clarification: It's only invalid to have super() call in any method...not just static methods.

(this is a recent constraint as of the Jan15 tc39 meeting)
Further clarification: super.whatever (member-expression-ish thing) appears to still be valid

I'd like to add a pull request to allow trailing commas in the list of arguments in function calls, which will help with VCS authorship attribution.

ES7 Proposals: https://github.com/tc39/ecma262
Specific proposal for this change: https://github.com/jeffmo/es-trailing-function-commas

Syntax:

Per Rev 32 (Feb 2, 2015) of the draft spec, the relevant grammar is on Section 14.4 Generator Function Definitions:

GeneratorMethod[Yield] :
    * PropertyName[?Yield] ( StrictFormalParameters[Yield,GeneratorParameter] )  { GeneratorBody[Yield]  }

GeneratorDeclaration[Yield, Default] :
    function * BindingIdentifier[?Yield] ( FormalParameters[Yield, GeneratorParameter] ) { GeneratorBody[Yield] }
    [+Default] function * ( FormalParameters[Yield, GeneratorParameter] ) { GeneratorBody[Yield] }

GeneratorExpression :
    function * BindingIdentifier[Yield]opt ( FormalParameters[Yield,GeneratorParameter] ) { GeneratorBody[Yield] }

GeneratorBody[Yield] :
    FunctionBody[?Yield]

YieldExpression[In] :
    yield
    yield [no LineTerminator here] [Lexical goal InputElementRegExp] AssignmentExpression[?In, Yield]
    yield [no LineTerminator here] * [Lexical goal InputElementRegExp] AssignmentExpression[?In, Yield]

AssignmentExpression[In, Yield] :
    [+Yield] YieldExpression[?In]

Spec:

https://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator-function-definitions

Relevant AST interfaces (from https://github.com/estree/estree):

Functions:

extend interface Function {
    defaults: [ Expression ];
    rest: Identifier | null;
    generator: boolean;
}

interface ArrowExpression <: Function, Expression {
    type: "ArrowExpression";
    params: [ Pattern ];
    defaults: [ Expression ];
    rest: Identifier | null;
    body: BlockStatement | Expression;
    generator: boolean;
    expression: boolean;
}

YieldExpression:

interface YieldExpression <: Expression {
    type: "YieldExpression";
    argument: Expression | null;
}

See also:

• Esprima generator support from harmony branch: https://code.google.com/p/esprima/issues/detail?id=287
• V8 generator support: https://code.google.com/p/v8/issues/detail?id=2355

Remaining Tasks:

• Review V8 error messages on generator early error
• Ensure the proper handling of yield* (old issue 617)

Syntax:

(TBD)

Spec:

(TBD)

Relevant AST interfaces (from https://github.com/estree/estree): (TBD)

Early Errors:

(TBD)

Related Tasks:

• Ensure that binding patterns are supported (old issue 570)

Syntax:

ComputedPropertyName[Yield] :
    [ AssignmentExpression[In, ?Yield] ]

Referred to by:

PropertyName[Yield,GeneratorParameter] :
    LiteralPropertyName
    [+GeneratorParameter] ComputedPropertyName
    [~GeneratorParameter] ComputedPropertyName[?Yield]

Early errors:

None.

Spec:

12.2.5 Object Initializer

See also

Esprima issue on Google Code
V8 support for computed property names
Error messages in V8

Syntax:

@ariya @jeffmo can you fill this in perhaps?

Spec:

@ariya @jeffmo can you fill this in perhaps?

Remaining Tasks:

• Review and Test Token Generation
• Review Error Messages
• review following commits for completeness e1ee12b 6789881 ae14b2c d3702a2

Parameters in ArrowFunctionExpression are not checked against strict mode restrictions if the strict mode is entered by a use strict directive directly inside the body.

For example:

eval => { "use strict"; }

should be an early error.

ArrowFunctionExpression also does not allow duplicate parameters, which is different from other simple parameter list.

In order to land classes, we must:

• Review and Test Token Generation
• Review Error Messages
• @ariya @jeffmo can you fill in more details here?

I did try tokenize this code:

var argv = parse(['moo'] , {
        boolean: [
            't' , 'verbose'
        ],
        default: {
            verbose: false,
            t: false
        }
    });

In result, token of identifier "default" was "Keyword" instead of "Identifier".

All of the following are valid ES6 and fail in current harmony:

• function a({x = 10}) {}
• function a({x = 10, y: { z = 10 }}) {}
• ({x = 10}) => x
• ({x = 10, y: { z = 10 }}) => [x,y]
• [a=10] = 0
• var {a = 10} = {}

Much more information about the expected implementation can be found here:
estree/estree#13

Now that Node.js 0.12 has been released, that is what should be used instead of 0.11.

In addition, io.js should be tested as well.

We should take a page from espree here and break out the test files into much smaller pieces organized by the main language feature they are testing.

Right now it is unwieldily working with the giant file, and intimidating to newer contributors, like myself.

Syntax:

ClassDeclaration[Yield, Default] :
  class BindingIdentifier[?Yield] ClassTail[?Yield]
  [+Default] class ClassTail[?Yield]
ClassExpression[Yield,GeneratorParameter] :
  class BindingIdentifier[?Yield]opt ClassTail[?Yield,?GeneratorParameter]
ClassTail[Yield,GeneratorParameter] :
  [~GeneratorParameter] ClassHeritage[?Yield]opt { ClassBody[?Yield]opt }
  [+GeneratorParameter] ClassHeritageopt { ClassBodyopt }
ClassHeritage[Yield] :
  extends LeftHandSideExpression[?Yield]
ClassBody[Yield] :
  ClassElementList[?Yield]
ClassElementList[Yield] :
  ClassElement[?Yield]
  ClassElementList[?Yield] ClassElement[?Yield]
ClassElement[Yield] :
  MethodDefinition[?Yield]
  static MethodDefinition[?Yield]
  ;

Spec:

https://people.mozilla.org/~jorendorff/es6-draft.html#sec-class-definitions

Remaining Tasks:

• Review and Test Token Generation
• Review Error Messages

(Migrated from https://code.google.com/p/esprima/issues/detail?id=591).

A line terminator before => should trigger an error.
Per Rev 32 (February 2, 2015) of the draft spec, Section 14.2, the grammar is:

ArrowFunction[In, Yield] :
  ArrowParameters[?Yield] [no LineTerminator here] => ConciseBody[?In]

How to reproduce the bug:

esprima.parse("()\n=> 42;")

Current behavior: no error.
Expected behavior: a syntax error, e.g. "Illegal newline before arrow".

Consider the following test code (parsing in tolerant mode):

require('./esprima').parse('if(foo.bar === 1', { tolerant: true })

The current master branch will thrown an exception due to the error Line 1: Unexpected end of input.

If this feature is implemented, it will return an AST because the missing ) is tolerated. The error will be still listed in the errors array.

(Migrated from https://code.google.com/p/esprima/issues/detail?id=553, as reported by @mrennie)

Integration details to follow. Just wanted to capture the action item for now.

To demonstrate the issue, run the following script:

var esprima = require('./esprima');
var code = '/* answer */ 42';
var tree = esprima.parse(code, { attachComment: true });
console.log(typeof tree.body[0].range);

The expected output is undefined. Since range option is not specified, it should default to false and hence every node will not have range property.

The current master branch produces the output object instead.

(Migrated from https://code.google.com/p/esprima/issues/detail?id=511)

12.14.5 Destructuring Assignment

They are used in the left hand side of an assignment expression when = is the assignment operator, or at the LeftHandSideExpression position of a for-in or a for-of loop.

Referred to by:

• 12.14.1 Static Semantics: Early Errors
• 13.6.4.1 Static Semantics: Early Errors

Syntax:

AssignmentPattern[Yield] :
  ObjectAssignmentPattern[?Yield]
  ArrayAssignmentPattern[?Yield]

ObjectAssignmentPattern[Yield] :
  { }
  { AssignmentPropertyList[?Yield] }
  { AssignmentPropertyList[?Yield] , }

ArrayAssignmentPattern[Yield] :
  [ Elisionopt AssignmentRestElement[?Yield]opt ]
  [ AssignmentElementList[?Yield] ]
  [ AssignmentElementList[?Yield] , Elisionopt AssignmentRestElement[?Yield]opt ]

AssignmentPropertyList[Yield] :
  AssignmentProperty[?Yield]
  AssignmentPropertyList[?Yield] , AssignmentProperty[?Yield]

AssignmentElementList[Yield] :
  AssignmentElisionElement[?Yield]
  AssignmentElementList[?Yield] , AssignmentElisionElement[?Yield]

AssignmentElisionElement[Yield] :
  Elisionopt AssignmentElement[?Yield]

AssignmentProperty[Yield] :
  IdentifierReference[?Yield] Initializer[In,?Yield]opt
  PropertyName : AssignmentElement[?Yield]

AssignmentElement[Yield] :
  DestructuringAssignmentTarget[?Yield] Initializer[In,?Yield]opt

AssignmentRestElement[Yield] :
  ... DestructuringAssignmentTarget[?Yield]

DestructuringAssignmentTarget[Yield] :
  LeftHandSideExpression[?Yield]

AssignmentProperty : IdentifierReference Initializeropt

DestructuringAssignmentTarget : LeftHandSideExpression

BindingPattern[Yield,GeneratorParameter] :
  ObjectBindingPattern[?Yield,?GeneratorParameter]
  ArrayBindingPattern[?Yield,?GeneratorParameter]

ObjectBindingPattern[Yield,GeneratorParameter] :
  { }
  { BindingPropertyList[?Yield,?GeneratorParameter] }
  { BindingPropertyList[?Yield,?GeneratorParameter] , }

ArrayBindingPattern[Yield,GeneratorParameter] :
  [ Elisionopt BindingRestElement[?Yield, ?GeneratorParameter]opt ]
  [ BindingElementList[?Yield, ?GeneratorParameter] ]
  [ BindingElementList[?Yield, ?GeneratorParameter] , Elisionopt BindingRestElement[?Yield, ?GeneratorParameter]opt ]

BindingPropertyList[Yield,GeneratorParameter] :
  BindingProperty[?Yield, ?GeneratorParameter]
  BindingPropertyList[?Yield, ?GeneratorParameter] , BindingProperty[?Yield, ?GeneratorParameter]

BindingElementList[Yield,GeneratorParameter] :
  BindingElisionElement[?Yield, ?GeneratorParameter]
  BindingElementList[?Yield, ?GeneratorParameter] , BindingElisionElement[?Yield, ?GeneratorParameter]

BindingElisionElement[Yield,GeneratorParameter] :
  Elisionopt BindingElement[?Yield, ?GeneratorParameter]

BindingProperty[Yield,GeneratorParameter] :
  SingleNameBinding[?Yield, ?GeneratorParameter]
  PropertyName[?Yield, ?GeneratorParameter] : BindingElement[?Yield, ?GeneratorParameter]

BindingElement[Yield,GeneratorParameter] :
  SingleNameBinding[?Yield, ?GeneratorParameter]
  [+GeneratorParameter] BindingPattern[?Yield,GeneratorParameter] Initializer[In]opt
  [~GeneratorParameter] BindingPattern[?Yield] Initializer[In, ?Yield]opt

SingleNameBinding [Yield, GeneratorParameter] :
  [+GeneratorParameter] BindingIdentifier[Yield] Initializer[In]opt
  [~GeneratorParameter] BindingIdentifier[?Yield] Initializer[In, ?Yield]opt

BindingRestElement[Yield, GeneratorParameter] :
  [+GeneratorParameter] ... BindingIdentifier[Yield]
  [~GeneratorParameter] ... BindingIdentifier[?Yield]

interface ObjectPattern <: Pattern {
    type: "ObjectPattern";
    properties: [ { key: Literal | Identifier, value: Pattern } ];
}

interface ArrayPattern <: Pattern {
    type: "ArrayPattern";
    elements: [ Pattern | null ];
}

typedef (ObjectBinding or ArrayBinding or BindingIdentifier or MemberExpression) Binding;


interface BindingWithDefault : Node {
  attribute (ObjectBinding or ArrayBinding or BindingIdentifier) binding;
  attribute Expression init;
};

interface BindingIdentifier : Node {
  attribute Identifier identifier;
};

interface ArrayBinding : Node {
  attribute (Binding or BindingWithDefault)?[] elements;
  attribute BindingIdentifier? restElement;
};

interface ObjectBinding : Node {
  attribute BindingProperty[] properties;
};

interface BindingProperty : Node { };

interface BindingPropertyIdentifier : BindingProperty {
  attribute BindingIdentifier identifier;
  attribute Expression? init;
};

interface BindingPropertyProperty : BindingProperty {
  attribute PropertyName name;
  attribute (Binding or BindingWithDefault) binding;
};


interface PropertyName : Node { };

interface ComputedPropertyName : PropertyName {
  attribute Expression value;
};

interface StaticPropertyName : PropertyName {
  attribute string value;
};

Currently esprima parses this as a function expression (probably because, before ES6, only function expressions could be nameless...not function decls).

However, in the export default grammar, this should be parsed as a special "HoistableDeclaration" which allows for nameless (yet hoisted) function declarations:

https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports

While working through adding tokens to the harmonymoduletest file, I've stumbled on something that I'm not sure is a bug, but seems off: In all import and export statements, as is listed as an "Identifier", when it seems like it should be a "Keyword".

The spec doesn't seem to list it as a keyword, but the syntax section of export (https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports) seems like, given the export/import context, it should be one.

From @RReverser in https://code.google.com/p/esprima/issues/detail?id=567

What steps will reproduce the problem?

1. Parse 'x => 1' with esprima.parse to ast variable.
2. Check out type of ast.body[0].expression.

What is the expected output?
'ArrowExpression' (as stated on https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Parser_API page)

What do you see instead?
'ArrowFunctionExpression'

I suppose this is by design, but would be great to fix either MDN wiki page or Esprima's output type so all the AST tools developers could follow the same specification and expect same results.