Bug 201897

Summary: Syntax checker should report duplicate __proto__ properties
Product: WebKit Reporter: Tadeu Zagallo <tzagallo>
Component: JavaScriptCoreAssignee: Tadeu Zagallo <tzagallo>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, ews-watchlist, keith_miller, mark.lam, msaboff, saam, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch for landing none

Tadeu Zagallo
Reported 2019-09-17 21:10:52 PDT
Attachments
Patch (7.00 KB, patch)
2019-09-17 22:44 PDT, Tadeu Zagallo
no flags
Patch for landing (8.13 KB, patch)
2019-09-19 10:49 PDT, Tadeu Zagallo
no flags
Tadeu Zagallo
Comment 1 2019-09-17 22:44:21 PDT
Mark Lam
Comment 2 2019-09-18 08:10:35 PDT
Comment on attachment 379022 [details] Patch For a change like this, can you run test262 to make sure there are no regressions? I wonder what was the rationale for having a different parseStrictObjectLiteral() in the first place.
Mark Lam
Comment 3 2019-09-18 08:44:36 PDT
Comment on attachment 379022 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=379022&action=review r=me if test262 passes. > Source/JavaScriptCore/ChangeLog:14 > + When syntax checking in sloppy mode, we call parseObjectLiteral, which does not fill the > + property names and therefore fails to detect the duplicate __proto__ properties. We replace > + parseObjectLiteral with the strict version since: > + - the only difference between parseObjectLiteral and parseStrictObjectLiteral seems to be > + whether we store the properties' names > + - parseObjectLiteral has to fallback to parseStrictObjectLiteral in the presence of getters/setters. Ok, I think I understand the difference now. parseObjectLiteral() passes TreeBuilder::DontBuildStrings to the Lexer, but parseStrictObjectLiteral() does not. This appears to be an optimization that went wrong, because the parser relies on getting the token strings in order to do the redefined __proto__ check. But since it told the lexer not to build this token (which it wrongly presumed is unnecessary work for the SyntaxChecker), the test fails. It is safe to always use parseStrictObjectLiteral() instead because there is actually no semantic difference in terms of "strict" vs "sloppy": parseStrictObjectLiteral() is also misnamed. Can you please put these details in the ChangeLog? You should still run test262 to make sure there are no hidden surprises here.
Tadeu Zagallo
Comment 4 2019-09-18 18:51:30 PDT
Thanks for the review. I checked test262 and JetStream2 and it seems all good. I'll update the ChangeLog before landing it.
Tadeu Zagallo
Comment 5 2019-09-19 10:49:46 PDT
Created attachment 379148 [details] Patch for landing
WebKit Commit Bot
Comment 6 2019-09-19 11:45:19 PDT
Comment on attachment 379148 [details] Patch for landing Clearing flags on attachment: 379148 Committed r250098: <https://trac.webkit.org/changeset/250098>
WebKit Commit Bot
Comment 7 2019-09-19 11:45:20 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.