Reason for revert:
Issue https://bugs.chromium.org/p/chromium/issues/detail?id=677055 . I'll send out a follow-on reland, as it should still be possible to eliminate the redundant type system.
Original issue's description:
> [intl] Remove redundant type checking system
>
> Previously, the Intl implementation tracked types two ways:
> - In the intl_initialized_marker_symbol
> - In various named properties of the intl_impl_object_symbol value
>
> As far as I can tell, these will never disagree with each other,
> modulo bugs in Intl itself. This patch removes the second type
> checking system.
>
> BUG=v8:5751
>
> Review-Url: https://codereview.chromium.org/2591203002
> Cr-Commit-Position: refs/heads/master@{#41941}
> Committed: 0d5561b64dTBR=yangguo@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5751
Review-Url: https://codereview.chromium.org/2601783002
Cr-Commit-Position: refs/heads/master@{#41958}
ECMA 402 v2 made Intl constructors more strict in terms of how they would
initialize objects, refusing to initialize objects which have already
been constructed. However, when Chrome tried to ship these semantics,
we ran into web compatibility issues.
This patch tries to square the circle and implement the simpler v2 object
semantics while including a compatibility workaround to allow objects to
sort of be initialized later, storing the real underlying Intl object
in a symbol-named property.
The new semantics are described in this PR against the ECMA 402 spec:
https://github.com/tc39/ecma402/pull/84
BUG=v8:4360, v8:4870
LOG=Y
Review-Url: https://codereview.chromium.org/2582993002
Cr-Commit-Position: refs/heads/master@{#41943}
Previously, the Intl implementation tracked types two ways:
- In the intl_initialized_marker_symbol
- In various named properties of the intl_impl_object_symbol value
As far as I can tell, these will never disagree with each other,
modulo bugs in Intl itself. This patch removes the second type
checking system.
BUG=v8:5751
Review-Url: https://codereview.chromium.org/2591203002
Cr-Commit-Position: refs/heads/master@{#41941}
The Intl implementation included manual checks to see if they were
being called as a constructor. However, these checks are redundant,
as %FunctionRemovePrototype has already marked the functions as
un-constructable. This path removes the unnecessary checks.
R=yangguo
Review-Url: https://codereview.chromium.org/2587713002
Cr-Commit-Position: refs/heads/master@{#41867}
Previously, the Intl.DateTimeFormat constructor and other related paths had
a bug where the options bag passed in would be modified in place. This patch
makes V8's Intl implementation follow the specification's logic to avoid
such a modification.
BUG=v8:4219
Review-Url: https://codereview.chromium.org/2587703002
Cr-Commit-Position: refs/heads/master@{#41826}
Use FastAsciiConvert (as used by Unibrow) for i18n-aware
case conversion with --icu_case_mapping.
Move FastAsciiConvert to src/string-case.cc so that it can be used
by both runtime-{string,i18n}.
Add more tests.
BUG=v8:4477,v8:4476
TEST=intl/general/case*
Review-Url: https://codereview.chromium.org/2533983006
Cr-Commit-Position: refs/heads/master@{#41821}
Due to a typo in runtime-i18n.js, 'ç'(U+00E7) was not uppercased while
'÷'(U+00F7) was incorrectly uppercased to '×'(U+00D7).
Add a comprehensive test for Latin-1 supplemental block (U+00A0 ~ U+00FF).
(they're special-cased for speed-up and needs to have a test for the range.).
TEST=intl/general/case-mapping
BUG=v8:5681
Review-Url: https://codereview.chromium.org/2533033003
Cr-Commit-Position: refs/heads/master@{#41331}
With this change, WebAssembly.Memory objects have backing stores allocated as an
8GB region where everything beyond the size of the Wasm heap is inaccessible.
GrowMemory is now implemented by changing the protection on the guard regions to
make the new portions of the heap accessible.
Guard pages are not enabled by default, but this change adds a flag and a test
variant to make sure we get test coverage on them.
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
Review-Url: https://codereview.chromium.org/2396433008
Cr-Commit-Position: refs/heads/master@{#41089}
ICU now supports uppercasing in Greek via its regular uppercasing API.
So, there's no need to use a slow transliteration API for uppercasing
in Greek.
This CL includes rolling ICU to ICU 58.1.
Besides, drop intl402/Intl/getCanonicalLocales/weird-cases from
test262.status because it passes now with ICU 58.1.
BUG=chromium:637001,v8:5012
Review-Url: https://codereview.chromium.org/2491333003
Cr-Commit-Position: refs/heads/master@{#41009}
This flag has been flipped off since 52, so it is due for removal.
R=adamk@chromium.org,caitp@igalia.com
BUG=v8:3785
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng
Review-Url: https://codereview.chromium.org/2268633002
Cr-Commit-Position: refs/heads/master@{#39435}
Spec discussion: https://github.com/tc39/ecma402/issues/30
It's in stage 4 and Firefox has already implemented it.
For now, it's added to HARMONY_IN_PROGRESS bucket behind
'--datetime-format-to-parts' flag.
BUG=v8:5244
TEST=intl/date-format/date-format-to-parts.js
TEST=test262/intl402/DateTimeFormat/prototype/formatToParts/*
Review-Url: https://codereview.chromium.org/2273953003
Cr-Commit-Position: refs/heads/master@{#39225}
Language tags with Unicode extensions can have multiple subtags
for a key (e.g. -ca-ismalic-civil has 'islamic-civi' for 'ca').
BUG=v8:4749
TEST=intl/date-format/calendar-with-multiple-type-subtags.js
Review-Url: https://codereview.chromium.org/2248563003
Cr-Commit-Position: refs/heads/master@{#38692}
Throw 'Range Error: invalid string length' when the result of
case mapping is longer than the max string length (kMaxLength in
objects.h = 1 << 28 - 16).
This is for case mapping with ICU.
BUG=v8:5271
TEST=intl/general/case-mapping.js with --icu_case_mapping
Review-Url: https://codereview.chromium.org/2236593002
Cr-Commit-Position: refs/heads/master@{#38565}
The Intl code previously called the initial value of String.prototype.split
for some internal operations. However, this did not have the intended effect
as Intl only needs to split strings by strings, but String.prototype.split
has integration with Symbol.split for RegExps.
This patch replaces the calls of StringSplit in the Intl implementation
with direct calls to the %StringSplit runtime function to avoid the issue.
R=yangguo@chromium.org
BUG=v8:5179
Review-Url: https://codereview.chromium.org/2126073002
Cr-Commit-Position: refs/heads/master@{#37615}
intl/number-format/parse-percent.js
intl/date-format/parse-mdyhms.js
intl/number-format/parse-decimal.js
intl/date-format/parse-MMMdy.js
Also added a few more test cases.
BUG=v8:3454
TEST=The tests listed above.
Review-Url: https://codereview.chromium.org/1988073003
Cr-Commit-Position: refs/heads/master@{#36555}
This patch ensures that Intl bound method getters can't be retargeted
to other Intl types. If that were to happen, then a RUNTIME_ASSERT
would trigger later. This patch throws a TypeError instead, as the
specification requires.
BUG=v8:4870
Review-Url: https://codereview.chromium.org/1986763003
Cr-Commit-Position: refs/heads/master@{#36330}
This patch removes the following properties, as their use count is
very low, they are V8-only, and not on a standards track.
- v8Parse
- resolved
- pattern
v8BreakIterator is left in as it has significantly more usage.
BUG=v8:3785
R=adamk,jshin@chromium.org
Review-Url: https://codereview.chromium.org/1968893002
Cr-Commit-Position: refs/heads/master@{#36190}
When I18N is enabled, use ICU's case conversion API and transliteration
API [1] to implement String.prototype.to{Upper,Lower}Case and
String.prototype.toLocale{Upper,Lower}Case.
* ICU-based case conversion was implemented in runtime-i18n.cc/i18n.js
* The above 4 functions are overridden with those in i18n.js when
--icu_case_mapping flag is turned on. To control the override by the flag,
they're overriden in icu-case-mapping.js
Previously, toLocale{U,L}Case just called to{U,L}Case so that they didn't
support locale-sensitive case conversion for Turkic languages (az, tr),
Greek (el) and Lithuanian (lt).
Before ICU APIs for the most general case are called, a fast-path for Latin-1
is tried. It's taken from Blink and adopted as necessary. This fast path
is always tried for to{U,L}Case. For toLocale{U,L}Case, it's only taken
when a locale (explicitly specified or default) is not in {az, el, lt, tr}.
With these changes, a build with --icu_case_mapping=true passes a bunch
of tests in test262/intl402/Strings/* and intl/* that failed before.
Handling of pure ASCII strings (aligned at word boundary) are not as fast
as Unibrow's implementation that uses word-by-word case conversion. OTOH,
Latin-1 input handling is faster than Unibrow. General Unicode input
handling is slower but more accurate.
See https://docs.google.com/spreadsheets/d/1KJCJxKc1FxFXjwmYqABS0_2cNdPetvnd8gY8_HGSbrg/edit?usp=sharing for the benchmark.
This CL started with http://crrev.com/1544023002#ps200001 by littledan@,
but has changed significantly since.
[1] See why transliteration API is needed for uppercasing in Greek.
http://bugs.icu-project.org/trac/ticket/10582
R=yangguo
BUG=v8:4476,v8:4477
LOG=Y
TEST=test262/{built-ins,intl402}/Strings/*, webkit/fast/js/*, mjsunit/string-case,
intl/general/case*
Review-Url: https://codereview.chromium.org/1812673005
Cr-Commit-Position: refs/heads/master@{#36187}
This prepares for pulling chromium's build as dependency for
gn. After this, the files in build and gypfiles need to stay
in sync until chromium is updated.
BUG=chromium:474921
LOG=n
Review-Url: https://codereview.chromium.org/1848553003
Cr-Commit-Position: refs/heads/master@{#35898}
Nothing too important, but it helps localizing the cause of an error
much faster.
By the way, I also changed the output for assertThrows and
assertDoesNotThrow a bit.
All new arguments are optional, so everything is backwards compatible.
R=jfb@chromium.org, titzer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1866693002
Cr-Commit-Position: refs/heads/master@{#35322}
The Intl object used to keep around functions which are bound to the
receiver and memoized in the object (as required by the ECMA-402 spec)
in ordinary properties with names like __boundformat__. This patch
instead stores those methods in private symbol properties, so they are
not exposed to users. A search in GitHub didn't find any uses of
__boundformat__ (whereas the same search found plenty of usages of
other V8 Intl features), so I think this should be fine in terms of
web compatibility.
BUG=v8:3785
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1728823002
Cr-Commit-Position: refs/heads/master@{#34230}
A couple of the Intl tests made calls to getDefaultTimeZone(), which
doesn't exist in V8; however, these were not core to the test. Rather
than marking the whole test as failing, just comment out that
unimportant part of the test.
R=adamk
Review URL: https://codereview.chromium.org/1522533003
Cr-Commit-Position: refs/heads/master@{#32819}
ECMAScript dates act as if the Gregorian changeover happened at the
beginning of time. This patch fixes up internationalized date
formatting to set that changeover properly, as opposed to the ICU
default which is in the 16th century.
BUG=chromium:537382
R=adamk,cira
LOG=Y
Review URL: https://codereview.chromium.org/1501113002
Cr-Commit-Position: refs/heads/master@{#32669}
The patch in https://crrev.com/ddb5c2d999c5ee6e31c4a9599bb3ddb293cc3f49
moved all fractional digit settings to default values due to a coding
error. These were not even correct default values, and users observed
errors where percentages were written as "23.0%" instead of "23%".
This patch fixes the setting propagation when appropriate and it changes
the default max fractional digits of a percentage to 0, per spec.
BUG=chromium:544122
R=mnita,jochen
CC=hichris123,adamk
LOG=Y
Review URL: https://codereview.chromium.org/1420883002
Cr-Commit-Position: refs/heads/master@{#31468}
Reason for revert:
Prime suspect in breakage of V8 Linux -- no snap
Original issue's description:
> [swarming] Isolate v8 testing.
>
> Add gyp support and isolates for default test suites.
> Add two default isolates, one (default) for using the
> test suite collection we call "default" on the bots. One
> (developer_default) for also supporting the way developers
> call the driver (i.e. without argument, which includes
> the unittests).
>
> BUG=chromium:535160
> LOG=n
>
> Committed: https://crrev.com/9bd83f58f29ab0c7c5b71b00bcb1df3a9e641f05
> Cr-Commit-Position: refs/heads/master@{#31081}
TBR=tandrii@chromium.org,jochen@chromium.org,maruel@chromium.org,machenbach@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:535160
Review URL: https://codereview.chromium.org/1370993008
Cr-Commit-Position: refs/heads/master@{#31084}
Add gyp support and isolates for default test suites.
Add two default isolates, one (default) for using the
test suite collection we call "default" on the bots. One
(developer_default) for also supporting the way developers
call the driver (i.e. without argument, which includes
the unittests).
BUG=chromium:535160
LOG=n
Review URL: https://codereview.chromium.org/1380593002
Cr-Commit-Position: refs/heads/master@{#31081}
Now run-tests.py understands "suite/foo/bar" with forward slashes for
command-line test selection on all test suites on all platforms.
Previously, file-based suites like mjsunit also accepted "mjsunit/foo\bar";
that behavior is sacrificed here in favor of unification. For the cctest
suite, OTOH, it wasn't possible on Windows to select specific tests at all.
Original review: https://codereview.chromium.org/1348653003/
This reverts commit 5f44a91059.
NOTRY=true
Review URL: https://codereview.chromium.org/1356613002
Cr-Commit-Position: refs/heads/master@{#30798}
Reason for revert:
mozilla tests are failing on Windows
Original issue's description:
> [test] Fix cctest path separators on Windows
>
> Now run-tests.py understands "suite/foo/bar" with forward slashes for
> command-line test selection on all test suites on all platforms.
>
> Previously, file-based suites like mjsunit also accepted "mjsunit/foo\bar";
> that behavior is sacrificed here in favor of unification. For the cctest
> suite, OTOH, it wasn't possible on Windows to select specific tests at all.
>
> Committed: https://crrev.com/b36cfdb39ae648b49a1396c4f669df9b1f57996c
> Cr-Commit-Position: refs/heads/master@{#30794}
TBR=machenbach@google.com,machenbach@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1349163002
Cr-Commit-Position: refs/heads/master@{#30795}
Now run-tests.py understands "suite/foo/bar" with forward slashes for
command-line test selection on all test suites on all platforms.
Previously, file-based suites like mjsunit also accepted "mjsunit/foo\bar";
that behavior is sacrificed here in favor of unification. For the cctest
suite, OTOH, it wasn't possible on Windows to select specific tests at all.
Review URL: https://codereview.chromium.org/1348653003
Cr-Commit-Position: refs/heads/master@{#30794}
NumberFormat previously just used a min of 0 digits after the decimal and a max of 3. This CL changes it so that we use the ICU currency data, and set the min and max to the number of numbers after the decimal point for each currency.
This CL also fixes a small bug where if the minimum fraction digits is above 3 but the maximum fraction digits isn't set, then it returns with only three numbers after the decimal point.
BUG=435465,473104,304722
LOG=Y
Review URL: https://codereview.chromium.org/1231613006
Cr-Commit-Position: refs/heads/master@{#29734}
ES5.1 section 6 ("Source Text"):
"Throughout the rest of this document, the phrase “code unit” and the
word “character” will be used to refer to a 16-bit unsigned value
used to represent a single 16-bit unit of text."
This changed in ES6 draft section 10.1 ("Source Text"):
"The ECMAScript code is expressed using Unicode, version 5.1 or later.
ECMAScript source text is a sequence of code points. All Unicode code
point values from U+0000 to U+10FFFF, including surrogate code points,
may occur in source text where permitted by the ECMAScript grammars."
This patch is to reflect this spec change.
BUG=v8:3617
LOG=Y
R=jochen@chromium.org
Review URL: https://codereview.chromium.org/640193002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24510 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
BUG=v8:2943
LOG=Y
TEST=Unit tests for "real life" use cases, edge cases, various types of normalization.
==========================
This is identical to the previous CL
https://codereview.chromium.org/40133004/
with two differences:
* Added a dummy implementation of String.prototype.normalize to be used when v8 is compiled without intl support
* Rebased the the test files for webkit. That was the only reason for the previous failure (and revert).
Thank you,
Mihai
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/68133016
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18972 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Reverting reverted r17148 and fixing build (test) breakage by side stepping the Windows vs. Linux issue of different Date object for the same millisecond time stamp.
We do that by using UTC Date methods (they eliminate DST problems).
Windows:
new Date(129193200000);
Sun Feb 03 1974 23:00:00 GMT-0800 (Pacific Standard Time)
Linux:
new Date(129193200000);
Mon Feb 04 1974 00:00:00 GMT-0700 (PST)
BUG=2919
R=dslomov@chromium.org, mnita@google.com
Review URL: https://codereview.chromium.org/26918002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17171 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
