[webkit-changes] [WebKit/WebKit] 89c0d4: [JSC] Array literal parsing should lex StringLiter...

[Yusuke Suzuki]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 89c0d4c38e9a62fe1dfdf430fc3624b6bf1db0f8
      https://github.com/WebKit/WebKit/commit/89c0d4c38e9a62fe1dfdf430fc3624b6bf1db0f8
  Author: Yusuke Suzuki <ysuzuki at apple.com>
  Date:   2022-10-06 (Thu, 06 Oct 2022)

  Changed paths:
    A JSTests/stress/array-literal-lexing-for-class-public-fields.js
    M Source/JavaScriptCore/parser/Parser.cpp

  Log Message:
  -----------
  [JSC] Array literal parsing should lex StringLiteral in the end of parsing
https://bugs.webkit.org/show_bug.cgi?id=245066
rdar://99815328

Reviewed by Mark Lam.

public class field can introduce a case that string literal after the array literal can have
a semantically meaningful content. Previously, we only checked it is string, and we didn't need
to have a string content itself for this case,

    [ ] "Hello"

But now, if it is used with class public field, then we need to know the content of the string to
emit a syntax error based on that.

    class A {
        g = []
        "constructor"() { }
    }

This patch drops array literal parsing's DontBuildStrings flag to lex the string content.

* JSTests/stress/array-literal-lexing-for-class-public-fields.js: Added.
(shouldBe):
(main.a.prototype.g.string_appeared_here):
(main.a):
(main):
* Source/JavaScriptCore/parser/Parser.cpp:
(JSC::Parser<LexerType>::parseArrayLiteral):

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