Possibly wrong tests detected

Hello
while stress-testing another parser with esprima, I came across a number of tests that pass while they should fail, or vice versa; yet another group of them pass as they are expected to, but they are possibly marking the locations wrongly:

fixtures/ES6/binding-pattern/array-pattern/for-let-let
fixtures/ES6/binding-pattern/object-pattern/for-let-let

The tests above are passing, even though their binding patterns require initializers.

fixtures/ES6/export-declaration/export-named-keyword-as-specifier
fixtures/ES6/export-declaration/export-named-keyword-specifier

The tests above are passing, even though an exported name must be an IdentifierReference when [Local] is not actually present in the production.

fixtures/ES6/yield/invalid-yield-strict-function-declaration
fixtures/ES6/yield/invalid-yield-strict-function-expression

In a similar issue from a while back, these turned out to be valid syntax -- 'use strict' affects the params and the body of a function, not BindingIdentifiers they might have.

fixtures/ES6/yield/yield-generator-arrow-default
fixtures/ES6/yield/yield-generator-default-parameter

yield is not allowed inside an arrow's (or a function's) parameters

fixtures/ES6/template-literals/literal-escape-sequences

\u0 is actually an invalid escape sequence.

fixtures/invalid-syntax/migrated_0201
fixtures/invalid-syntax/migrated_0202
fixtures/invalid-syntax/migrated_0205
fixtures/invalid-syntax/migrated_0206
fixtures/invalid-syntax/migrated_0208
fixtures/invalid-syntax/migrated_0234
fixtures/invalid-syntax/migrated_0235
fixtures/invalid-syntax/migrated_0236

they are actually valid -- just like this test: fixtures/ES6/yield/invalid-yield-strict-function-declaration.

fixtures/es2017/async/methods/invalid-async-class-getter 
fixtures/es2017/async/methods/invalid-async-class-setter 
fixtures/es2017/async/methods/invalid-static-async-class-getter 
fixtures/es2017/async/methods/invalid-static-async-class-setter 

I'm not a great spec reader, but despite what the tests' name suggest, ({ async get() {} }) is not even a getter!
(same goes for ({ async set() {} }), which is not a setter -- not to my limited knowledge at least.)

fixtures/es2017/async/arrows/async-arrow-object-expression-parameter
fixtures/es2017/async/arrows/async-arrow-pattern-parameter

the parameter in the AST's for the tests above has type ObjectExpression, while in fact it's an ObjectPatern

fixtures/es2017/async/arrows/async-arrow-spread

the AST for the test above has listed the parameter as having type SpreadElement, while in fact it has to be a RestElement.

fixtures/es2017/async/functions/export-default-async-function-expression.module
fixtures/es2017/async/functions/export-default-async-named-function-expression-await.module 
fixtures/es2017/async/functions/export-default-async-named-function-expression.module

FunctionExpression in the tests above should be FunctionDeclaration instead.

fixtures/es2017/async/methods/async-method-literal
fixtures/es2017/async/methods/async-method-number

the method names in the test cases above are Literals -- but in their corresponding AST json, an Identifier has been given instead.

fixtures/es2017/async/methods/async-method-await
fixtures/es2017/async/methods/async-method

the start location of the method's name is most probably off by a few characters.

fixtures/es2017/async/methods/class-async-method-computed

computed must be true, but it is not.

my $10000000000ZWD.

Review the listed fixtures under fixtures/ES6, fixtures/es2017, and fixtures/invalid-syntax, comparing each source case with its expected AST JSON and validity. Start with one fixture group, then run the relevant fixture tests to confirm parser output. Done means the affected validity results, node types, binding forms, and source locations match the stated ECMAScript expectations.