ASSERTION FAILED: inIndex != notFound in JSC::invalidParameterInSourceAppender()
authorsbarati@apple.com <sbarati@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 27 Apr 2017 02:28:39 +0000 (02:28 +0000)
committersbarati@apple.com <sbarati@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 27 Apr 2017 02:28:39 +0000 (02:28 +0000)
commit39d805cac5d4d68285115a6bc68e1cb767a275e7
tree27088223f2c3c86aa9a54a9b5ba115c88afc8450
parent86cab6ed99a218fb96e3684275522011f4830367
ASSERTION FAILED: inIndex != notFound in JSC::invalidParameterInSourceAppender()
https://bugs.webkit.org/show_bug.cgi?id=170924
<rdar://problem/31721052>

Reviewed by Mark Lam.

JSTests:

* stress/error-message-for-function-base-not-found.js: Added.
(assert):
(throw.new.Error):
* stress/error-messages-for-in-operator-should-not-crash.js: Added.
(catch):

LayoutTests/imported/w3c:

* web-platform-tests/css-timing-1/cubic-bezier-timing-functions-output-expected.txt:
* web-platform-tests/css-timing-1/frames-timing-functions-output-expected.txt:
* web-platform-tests/css-timing-1/step-timing-functions-output-expected.txt:

Source/JavaScriptCore:

The error message handler for "in" was searching for the literal
string "in". However, our parser incorrectly allows escaped characters
to be part of keywords. So this is parsed as "in" in JSC: "i\u006E".
It should not be parsed that way. I opened https://bugs.webkit.org/show_bug.cgi?id=171310
to address this issue.

Regardless, the error message handlers should handle unexpected text gracefully.
All functions that try to augment error messages with the goal of
providing a more textual context for the error message should use
the original error message instead of crashing when they detect
unexpected text.

This patch also changes the already buggy code that tries to find
the base of a function call. That could would fail for code like this:
"zoo.bar("/abc\)*/");". See https://bugs.webkit.org/show_bug.cgi?id=146304
It would think that the base is "z". However, the algorithm that tries
to find the base can often tell when it fails, and when it does, it should
happily return the approximate text error message instead of thinking
that the base is "z".

* runtime/ExceptionHelpers.cpp:
(JSC::functionCallBase):
(JSC::notAFunctionSourceAppender):
(JSC::invalidParameterInSourceAppender):

LayoutTests:

* js/let-syntax-expected.txt:

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@215852 268f45cc-cd09-0410-ab3c-d52691b4dbfc
12 files changed:
JSTests/ChangeLog
JSTests/stress/destructuring-assignment-accepts-iterables.js
JSTests/stress/error-message-for-function-base-not-found.js [new file with mode: 0644]
JSTests/stress/error-messages-for-in-operator-should-not-crash.js [new file with mode: 0644]
LayoutTests/ChangeLog
LayoutTests/imported/w3c/ChangeLog
LayoutTests/imported/w3c/web-platform-tests/css-timing-1/cubic-bezier-timing-functions-output-expected.txt
LayoutTests/imported/w3c/web-platform-tests/css-timing-1/frames-timing-functions-output-expected.txt
LayoutTests/imported/w3c/web-platform-tests/css-timing-1/step-timing-functions-output-expected.txt
LayoutTests/js/let-syntax-expected.txt
Source/JavaScriptCore/ChangeLog
Source/JavaScriptCore/runtime/ExceptionHelpers.cpp