-
Notifications
You must be signed in to change notification settings - Fork 472
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RAB: Integrate staging tests for the .toLocaleString method #4178
Conversation
assert.sameValue(Array.prototype.toLocaleString.call(fixedLength), '0,2,4,6'); | ||
assert.sameValue(Array.prototype.toLocaleString.call(fixedLengthWithOffset), '4,6'); | ||
assert.sameValue(Array.prototype.toLocaleString.call(lengthTracking), '0,2,4,6'); | ||
assert.sameValue(Array.prototype.toLocaleString.call(lengthTrackingWithOffset), '4,6'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per https://tc39.es/ecma262/#sec-array.prototype.tolocalestring, we are assuming the separator is ","
even though it's implementation-defined.
In fact, the spec text itself suggests using ", "
with a space. Engine262 does this, while all other engines that I tested use ","
without a space.
I think we might have to write these tests to be a bit more agnostic to the localized output.
Note you can get the separator by using [undefined,undefined].toLocaleString()
, and we should also call toLocaleString
with the argument "en-u-nu-latn"
to ensure that we get the right digit representations regardless of the locale in which the tests are executed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was unsure about whether to still pass en-u-nu-latn
to each invocation of toLocaleString like I suggested above. In the end I think it's OK not to; it would clutter up the tests quite a bit and I am sure there are a bunch of other existing tests that would fail if the default locale wasn't en
.
test/built-ins/Array/prototype/toLocaleString/user-provided-tolocalestring-shrink.js
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM after shortening listToString
test/built-ins/Array/prototype/toLocaleString/resizable-buffer.js
Outdated
Show resolved
Hide resolved
…des, while applying review changes from PRs for previously tested methods.
Co-authored-by: Philip Chimento <philip.chimento@gmail.com>
Co-authored-by: Philip Chimento <philip.chimento@gmail.com>
d13f304
to
55f5e11
Compare
of Array.prototype and TypedArray.prototype
This is part of PR #3888 to make reviewing easier. Includes changes to use the helper ./harness/resizableArrayBufferUtils.js