I think Adam has brought this up before. Scanner::BookmarkScope sort of implements that kind of logic, but the current implementation isn't suitable for your use case because it's opportunistic and will just fail to set a bookmark if the conditions are not quite right.
I don't think there is any super deep reason why this couldn't be generalized, but it'd be a good amount of work. The bookmark logic would have to be implemented for all stream classes (I only implemented it for some) and it would probably need to support several bookmarks (right now, there can only be one). It's finicky work: My implementation had several severe bugs, because I didn't properly handle some edge cases. Performance: There were several performance regressions, but I think I resolved those. There's a cost to setting a bookmark, so there would be performance issues if the number of bookmarks set would be rather large. Those should be fixable, too, but that would probably require significant rework of the current streams. Daniel On Mon, Nov 9, 2015 at 7:25 AM, Caitlin Potter <[email protected]> wrote: > This has been suggested previously, but shot down on the grounds of > performance (and difficulties with the way the Parser allocates variables, > etc). However, I'm bringing it up again, as it seems to be working well for > other implementations: > > Currently, JavaScriptCore has the novel concept of saving a position in > the token stream, and rewinding back to it if necessary. > > They are currently doing this at the start of every AssignmentExpression, > which begins with a peeked LBRACK or LBRACE, and which is not followed by > an ASSIGN token. It would follow that you'd also want to do this for > parenthesized Expressions that may be Arrow formals, although I don't see > this happening in their current implementation. > > It's been suggested that V8 does this before, but has been shot down each > time --- however, it looks like it potentially solves two problems: > > 1. the cover grammars may be parsed specially, rather than requiring > particular productions handle parsing several different ways > simultaneously, and drastically simplifying the parser > 2. it is possible to correctly ensure that appropriate code is produced. > Since the Parser is performing the desugaring (which does not occur in > JSC), eagerly rewriting AssignmentExpressions as destructuring assignment > can produce an AST which the BindingPattern rewriter simply can't deal > with, and which would be difficult for it to deal with. > > Might be worth coming back to the topic if it works well for other > implementations, which still seem to perfectly adequately compile JS on the > web. > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
