Skip to content

V
V8
Switch branch/tag
  1. 10 Jul, 2018 1 commit
  3. 01 Feb, 2018 1 commit
  5. 31 Jan, 2018 2 commits
  7. 30 Jan, 2018 2 commits
  9. 18 Dec, 2017 1 commit
  11. 13 Dec, 2017 2 commits
  13. 12 Dec, 2017 1 commit
  15. 16 Nov, 2017 1 commit
  17. 27 Oct, 2017 1 commit
  19. 11 May, 2016 1 commit
    • jshin's avatar
      Use ICU case conversion/transliterator for case conversion · b348d47b
      jshin authored 
      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}
      b348d47b
  21. 29 Mar, 2016 1 commit
  23. 17 Sep, 2015 3 commits
  25. 11 Oct, 2013 1 commit
  27. 10 Oct, 2013 2 commits
  29. 01 Aug, 2013 1 commit
  31. 10 Jul, 2013 1 commit
  33. 18 Apr, 2013 1 commit
  35. 18 Jan, 2013 1 commit
  37. 22 Oct, 2012 1 commit
  39. 24 Sep, 2012 1 commit
  41. 10 Aug, 2012 1 commit
  43. 26 Jul, 2011 1 commit
  45. 31 May, 2011 1 commit
    • rossberg@chromium.org's avatar
      Implement set trap for proxies, and revamp class hierarchy in preparation: · 670f947a
      rossberg@chromium.org authored 
      - Introduce a class JSReceiver, that is a common superclass of JSObject and
  JSProxy. Use JSReceiver where appropriate (probably lots of places that we
  still have to migrate, but we will find those later with proxy test suite).

- Move appropriate methods to JSReceiver class (SetProperty,
  GetPropertyAttribute, Get/SetPrototype, Lookup, and so on).

- Introduce new JSFunctionProxy subclass of JSProxy. Currently only a stub.

- Overhaul enum InstanceType:
  * Introduce FIRST/LAST_SPEC_OBJECT_TYPE that ranges over all types that
    represent JS objects, and use that consistently to check language types.
  * Rename FIRST/LAST_JS_OBJECT_TYPE and FIRST/LAST_FUNCTION_CLASS_TYPE
    to FIRST/LAST_[NON]CALLABLE_SPEC_OBJECT_TYPE for clarity.
  * Eliminate the overlap over JS_REGEXP_TYPE.
  * Also replace FIRST_JS_OBJECT with FIRST_JS_RECEIVER, but only use it where
    we exclusively talk about the internal representation type.
  * Insert JS_PROXY and JS_FUNCTION_PROXY in the appropriate places.

- Fix all checks concerning classification, especially for functions, to
  use the CALLABLE_SPEC_OBJECT range (that includes funciton proxies).

- Handle proxies in SetProperty (that was the easiest part :) ).

- A few simple test cases.

R=kmillikin@chromium.org

Review URL: http://codereview.chromium.org/6992072

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8126 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      670f947a
  47. 15 Apr, 2011 1 commit
  49. 12 Apr, 2011 2 commits
  51. 21 Mar, 2011 1 commit
  53. 18 Mar, 2011 3 commits
  55. 10 Jan, 2011 1 commit
    • ricow@chromium.org's avatar
      Enable sharding of individual testsuites in tools/test.py · b4ea8c7f
      ricow@chromium.org authored 
      This patch enables two new flags for the tools/test.py script;
--shard-count - giving the ability to split the tests to be run
into shard-count chunks.
--shard-run - giving the ability to specify which of the shards to actually run.

Example
  tools/test.py -j15 --shard-count=2 --shard-run=1 mozilla
would split the mozilla tests into two chunks and run the tests in the first chunk

Running:
  tools/test.py -j15 --shard-count=2 --shard-run=1 mozilla
  tools/test.py -j15 --shard-count=2 --shard-run=2 mozilla
is equivalent (in terms of test coverage) of just running:
  tools/test.py -j15 mozilla

In addition, tests are now sorted before they are returned from the
test specific ListTests methods (sputnik and mozilla tests where
already sorted before they where returned).

This change is needed to split a single test suite over two slaves on
the waterfall.


Review URL: http://codereview.chromium.org/6127003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6248 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      b4ea8c7f
  57. 24 Aug, 2010 1 commit
  59. 14 Oct, 2009 1 commit
  61. 15 Sep, 2009 1 commit