If it parses successfully it will generate a expected.json for you when you run the test if it isn't provided

@hzoo thanks for pointing this out. I will check the fixtures and see whether the file is there.

@hzoo I didn't realize it but the expected.json was generated and seems to be fine.

@hzoo I have added additional test cases for testing "fringe" use cases of decorators and also invalid uses such as @a?b:c. The latter stands for arbitrary left hand side expressions which we must prevent here in order for being able to decorate generator functions.

Also adds missing tests such as You can't attach decorators to a class constructor and code requiring the asyncFunctions plugin. Including also decorating static [generator] methods.

See test/fixtures/experimental/uncategorized/[63..75].

I need you or someone else to review the generated expected.json files as I am not that familiar with the AST the babylon parser generates.

@hzoo @wycats How does or can the alternate use of parseExprSubscripts() instead of parseMaybeAssign() fit into the current decorator specificaiton proposal and how can it fit into the alternate proposal I made?

While parseMaybeAssign() is a realization of LeftHandSideExpression, what does parseExprSubscripts() stand for? Is it just IdentifierReference and CallExpression?

And since IdentifierReference also includes yield, isn't that way too much for a simple use of a decorator?

I'm concerned that this would be a breaking change, we'll need to work out how to coordinate it.

covered by #590