Fix parsing of optional chaining in new expressions and decorators

[adams85]

Takes a crack at #322 (However, addresses only new expressions because decorators seem to have bigger issues ATM).

The fix involves keeping track of the last processed token, which I'm not completely comfortably with TBH. But other approaches look much more complicated. Could someone more familiar with the parser take a look at this?

[lahma]

Now sure if I can be of much help here, always appreciate you improving the parsing though! I've usually looked at acorn for ideas on how to accomplish some specific parsing scenarios in the past.

[adams85]

Thanks for the tip. Acorn just passes a flag down the call stack to implement the necessary check. In Esprima it's a bit more complicated because ParseLeftHandSideExpression is not called directly but through IsolateCoverGrammar. So I had to introduce a new flag in JavaScriptParser.Context, which I wanted to avoid. However, this looks to be the correct way.

And while being at it, I also fixed #394.

[lahma]

LGTM, seems naturally follow common patterns like previous-reset for flags and reads well. Nicely done once again!

[adams85]

How about pushing out a new RC? :) If you could do it, I could finish the regex story in Jint.

[lahma]

I of course can, but would you like to do the honors this time? Just to make sure we don't have dependency on single entities (like me or Sebastien). Just create the tag with the name following earlier tags against latest main, push against origin and rock'n'roll 🚀

Just say so and I'll do it, just testing how you would feel about it (convo about whether to push is of course nice, but you master the features at the moment).

[adams85]

If it's that simple, no problem. :) I'll give it a shot.

[lahma]

What is this sorcery, you have accomplished the task of publishing an Esprima release to nuget.org, congrats! 🚀