fixes #13: limit decorator use to CallExpression and IdentifierReference

[silkentrance]

This is an initial stab at #13 that realizes the proposal wycats/javascript-decorators#66

What the patch does is replace the call to parseMaybeAssign() with parseExprSubscripts(), in addition it will also eat the first '@' as parseDecorator() gets called by parseExprOps().

Subsequently, CallExpression and IdentifierReference are realized with the benefit of being able to use subscripts, e.g. @decorators[Symbol](...) etc.

Not sure about the template handling also available in parseSubscripts(), though.

My initial integration tests using a real project seem to work fine. Needs additional work on the test cases though, see test/fixtures/experimental/uncategorized/63.

Also, the decorator must be made aware of the fact that it is decorating a generator function a/o an async function. But this is part of the transpiler is it not?

How do I create the expected.json?

[hzoo]

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

[silkentrance]

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

[silkentrance]

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

[silkentrance]

@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.

[silkentrance]

@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?

[sebmck]

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

[hzoo]

covered by #590