Summary: | [JSC] isStrWhiteSpace seems redundant with Lexer<UChar>::isWhiteSpace | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Ross Kirsling <ross.kirsling> | ||||||
Component: | JavaScriptCore | Assignee: | Ross Kirsling <ross.kirsling> | ||||||
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
Ross Kirsling
2018-11-08 15:14:15 PST
(In reply to Ross Kirsling from comment #0) > Note that while Lexer<UChar>::isWhiteSpace matches the current ES spec > (https://tc39.github.io/ecma262/#sec-white-space), isStrWhiteSpace > additionally looks for 0x000A, 0x000D, 0x2028, and 0x2029. Not sure whether > it's supposed to be doing so or not though. Oops, apparently those four are covered in the very next section (https://tc39.github.io/ecma262/#sec-line-terminators). So isStrWhiteSpace (whose name originates here: https://tc39.github.io/ecma262/#prod-StrWhiteSpace) includes line terminators and isWhiteSpace does not. I guess we still need two functions, but we can at least have one depend on the other. Created attachment 354294 [details]
Patch
(In reply to Ross Kirsling from comment #2) > Created attachment 354294 [details] > Patch I thought about making isStrWhiteSpace a static Lexer method, but since the spec uses it exclusively for numeric parsing, it's probably best left where it is. Comment on attachment 354294 [details]
Patch
nice. r=me
Created attachment 354307 [details]
Patch for landing
Comment on attachment 354307 [details] Patch for landing Clearing flags on attachment: 354307 Committed r238016: <https://trac.webkit.org/changeset/238016> All reviewed patches have been landed. Closing bug. |