Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JSC] Node's JSTokenLocation sometimes doesn't point to the start of an expression #22944

Conversation

shvaikalesh
Copy link
Member

@shvaikalesh shvaikalesh commented Jan 18, 2024

e0132b8

[JSC] Node's JSTokenLocation sometimes doesn't point to the start of an expression
https://bugs.webkit.org/show_bug.cgi?id=267728
<rdar://problem/121215280>

Reviewed by Justin Michaud.

Before this patch, if we tried to reparse at node->position(), we would fail with SyntaxError for
object / array literals, async (arrow) functions, and member expressions with `new` / optional chaining,
due to Node's JSTokenLocation not pointing to the start of an expression.

This change fixes JSTokenLocation to be correct for above-mentioned cases, enabling us to redesign
class field initializers reparsing, and also improves accuracy of expression divots by removing
lastTokenEndPosition() usage from OPENBRACKET / DOT / BACKQUOTE cases of parseMemberExpression().

lastTokenEndPosition() makes sense in case of e.g. parseArguments() because after it exits, the
current token is the next one after `)`, yet in the e.g. DOT case, lastTokenEndPosition() most
likely points to previous identifier, which might be even on a different line.

On top of that, this patch improves stack trace accuracy for `new new new C` expressions by
storing position of each NEW token in a vector.

Aligns stack traces (error locations) with V8 and SpiderMonkey, including for modified API test.

* JSTests/stress/regress-267728.js: Added.
* Source/JavaScriptCore/builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutable):
* Source/JavaScriptCore/parser/ASTBuilder.h:
(JSC::ASTBuilder::createNewExpr):
* Source/JavaScriptCore/parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parseObjectLiteral):
(JSC::Parser<LexerType>::parseArrayLiteral):
(JSC::Parser<LexerType>::parseAsyncFunctionExpression):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression):
(JSC::Parser<LexerType>::parseArrowFunctionExpression):
* Source/JavaScriptCore/parser/Parser.h:
* Source/JavaScriptCore/parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createNewExpr):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewConfiguration.mm:

Canonical link: https://commits.webkit.org/273255@main

fd3065e

Misc iOS, tvOS & watchOS macOS Linux Windows
βœ… πŸ§ͺ style βœ… πŸ›  ios βœ… πŸ›  mac βœ… πŸ›  wpe βœ… πŸ›  wincairo
βœ… πŸ§ͺ bindings βœ… πŸ›  ios-sim βœ… πŸ›  mac-AS-debug   πŸ§ͺ wpe-wk2
βœ… πŸ§ͺ webkitperl βœ… πŸ§ͺ ios-wk2 βœ… πŸ§ͺ api-mac βœ… πŸ§ͺ api-wpe
βœ… πŸ§ͺ ios-wk2-wpt βœ… πŸ§ͺ mac-wk1 βœ… πŸ›  gtk
  πŸ›  πŸ§ͺ jsc βœ… πŸ§ͺ api-ios βœ… πŸ§ͺ mac-wk2   πŸ§ͺ gtk-wk2
βœ… πŸ›  πŸ§ͺ jsc-arm64 βœ… πŸ›  tv βœ… πŸ§ͺ mac-AS-debug-wk2 βœ… πŸ§ͺ api-gtk
βœ… πŸ›  tv-sim βœ… πŸ›  jsc-armv7
βœ… πŸ›  watch   πŸ§ͺ jsc-armv7-tests
βœ… πŸ›  πŸ§ͺ unsafe-merge βœ… πŸ›  watch-sim

@shvaikalesh shvaikalesh requested a review from a team as a code owner January 18, 2024 23:31
@shvaikalesh shvaikalesh self-assigned this Jan 18, 2024
@shvaikalesh shvaikalesh added the JavaScriptCore For bugs in JavaScriptCore, the JS engine used by WebKit, other than kxmlcore issues. label Jan 18, 2024
Copy link
Contributor

@justinmichaud justinmichaud left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you mean line, not like in the commit message.

r=me, but let's wait for #22880 to land first.

@webkit-ews-buildbot webkit-ews-buildbot added the merging-blocked Applied to prevent a change from being merged label Jan 19, 2024
@shvaikalesh shvaikalesh removed the merging-blocked Applied to prevent a change from being merged label Jan 19, 2024
@shvaikalesh shvaikalesh force-pushed the eng/JSC-Nodes-JSTokenLocation-sometimes-doesnt-point-to-the-start-of-an-expression branch from 3a30199 to b96cbf4 Compare January 19, 2024 07:37
@webkit-ews-buildbot webkit-ews-buildbot added the merging-blocked Applied to prevent a change from being merged label Jan 19, 2024
@shvaikalesh shvaikalesh removed the merging-blocked Applied to prevent a change from being merged label Jan 19, 2024
@shvaikalesh shvaikalesh force-pushed the eng/JSC-Nodes-JSTokenLocation-sometimes-doesnt-point-to-the-start-of-an-expression branch from b96cbf4 to 76ad00b Compare January 19, 2024 22:10
@shvaikalesh shvaikalesh force-pushed the eng/JSC-Nodes-JSTokenLocation-sometimes-doesnt-point-to-the-start-of-an-expression branch from 76ad00b to fd3065e Compare January 19, 2024 23:58
@shvaikalesh shvaikalesh added the unsafe-merge-queue Applied to send a pull request to merge-queue, but skip building and testing label Jan 20, 2024
…an expression

https://bugs.webkit.org/show_bug.cgi?id=267728
<rdar://problem/121215280>

Reviewed by Justin Michaud.

Before this patch, if we tried to reparse at node->position(), we would fail with SyntaxError for
object / array literals, async (arrow) functions, and member expressions with `new` / optional chaining,
due to Node's JSTokenLocation not pointing to the start of an expression.

This change fixes JSTokenLocation to be correct for above-mentioned cases, enabling us to redesign
class field initializers reparsing, and also improves accuracy of expression divots by removing
lastTokenEndPosition() usage from OPENBRACKET / DOT / BACKQUOTE cases of parseMemberExpression().

lastTokenEndPosition() makes sense in case of e.g. parseArguments() because after it exits, the
current token is the next one after `)`, yet in the e.g. DOT case, lastTokenEndPosition() most
likely points to previous identifier, which might be even on a different line.

On top of that, this patch improves stack trace accuracy for `new new new C` expressions by
storing position of each NEW token in a vector.

Aligns stack traces (error locations) with V8 and SpiderMonkey, including for modified API test.

* JSTests/stress/regress-267728.js: Added.
* Source/JavaScriptCore/builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutable):
* Source/JavaScriptCore/parser/ASTBuilder.h:
(JSC::ASTBuilder::createNewExpr):
* Source/JavaScriptCore/parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parseObjectLiteral):
(JSC::Parser<LexerType>::parseArrayLiteral):
(JSC::Parser<LexerType>::parseAsyncFunctionExpression):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseMemberExpression):
(JSC::Parser<LexerType>::parseArrowFunctionExpression):
* Source/JavaScriptCore/parser/Parser.h:
* Source/JavaScriptCore/parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createNewExpr):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/WKWebViewConfiguration.mm:

Canonical link: https://commits.webkit.org/273255@main
@webkit-commit-queue webkit-commit-queue force-pushed the eng/JSC-Nodes-JSTokenLocation-sometimes-doesnt-point-to-the-start-of-an-expression branch from fd3065e to e0132b8 Compare January 20, 2024 03:11
@webkit-commit-queue
Copy link
Collaborator

Committed 273255@main (e0132b8): https://commits.webkit.org/273255@main

Reviewed commits have been landed. Closing PR #22944 and removing active labels.

@webkit-commit-queue webkit-commit-queue merged commit e0132b8 into WebKit:main Jan 20, 2024
@webkit-commit-queue webkit-commit-queue removed the unsafe-merge-queue Applied to send a pull request to merge-queue, but skip building and testing label Jan 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
JavaScriptCore For bugs in JavaScriptCore, the JS engine used by WebKit, other than kxmlcore issues.
Projects
None yet
5 participants