[Webkit-unassigned] [Bug 144955] [ES6] Implement ES6 arrow function syntax. Parser of arrow function with execution as common function

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jun 25 19:41:19 PDT 2015


--- Comment #91 from Yusuke Suzuki <utatane.tea at gmail.com> ---
Comment on attachment 255593
  --> https://bugs.webkit.org/attachment.cgi?id=255593

View in context: https://bugs.webkit.org/attachment.cgi?id=255593&action=review

I think only a few nits remains. Code becomes very simple, nice.
Thank you for your contributions. Sorry for troubling you by a long time review.

> Source/JavaScriptCore/parser/Parser.cpp:364
> +        

I think propagateError() is needed before `return sourceElements`.

> Source/JavaScriptCore/parser/Parser.cpp:1529
> +        endLocation.lineStartOffset = cachedInfo->lastTockenLineStartOffset;

Looks nice.

> Source/JavaScriptCore/parser/Parser.cpp:1570
> +        }

OK, looks nice.

> Source/JavaScriptCore/parser/Parser.cpp:1588
> +        info.startFunctionOffset = m_token.m_data.offset;

Still I don't understand why this line is needed.
`info.startFunctionOffset` is already adjusted in the
`info.startFunctionOffset = (info.functionBodyType == ArrowFunctionBodyBlock) ? m_token.m_data.offset : info.arrowFunctionOffset;`
part, right?

When setting info.startFunctionOffset previously, we already considered functionBodyType.
When block body functions come, we set `{`'s offset. And when expr body functions come, we set `=>`'s offset.
So this resetting is already done.

Anyway, if info.startFunctionOffset is modified after looking up the cacheInfo, cacheInfo's key becomes different.
So if this adjustment is needed, this need to be done before `if (const SourceProviderCacheItem* cachedInfo = TreeBuilder::CanUseFunctionCache ? findCachedFunctionInfo(info.startFunctionOffset) : 0) {` part. Reaching here, we already looked up the cache with the previous info.startFunctionOffset.

> Source/JavaScriptCore/parser/Parser.cpp:1628
> +#endif

Very nice :D

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150626/a68dae50/attachment.html>

More information about the webkit-unassigned mailing list