Bug 191439 – [JSC] isStrWhiteSpace seems redundant with Lexer<UChar>::isWhiteSpace

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Ross Kirsling]

isStrWhiteSpace in ParseInt.h seems redundant with Lexer<UChar>::isWhiteSpace and could probably be done away with.

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.

[Ross Kirsling]

(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.

[Ross Kirsling]

Created attachment 354294 [details]
Patch

[Ross Kirsling]

(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.

[Saam Barati]

Comment on attachment 354294 [details]
Patch

nice. r=me

[Ross Kirsling]

Created attachment 354307 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 354307 [details]
Patch for landing

Clearing flags on attachment: 354307

Committed r238016: <https://trac.webkit.org/changeset/238016>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/45934608>