1. 16 Jun, 2021 1 commit
  2. 15 Jun, 2021 1 commit
  3. 06 May, 2021 1 commit
  4. 29 Jan, 2021 1 commit
  5. 07 Jan, 2021 1 commit
  6. 20 Nov, 2020 1 commit
  7. 18 Nov, 2020 1 commit
  8. 24 Jul, 2020 1 commit
  9. 04 May, 2020 1 commit
  10. 18 Nov, 2019 1 commit
  11. 01 Oct, 2019 1 commit
  12. 16 Sep, 2019 1 commit
  13. 17 Jun, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Stricter object field verification, part 2 · 15ea19db
      Seth Brenith authored
      This change removes the special case in the Torque compiler for types
      that descend from JSObject: they will no longer get implicit
      "| Undefined" appended to their types for verification purposes. It
      removes any additional custom verification steps in objects-debug that
      are made redundant by that change.
      
      In order to do so safely, I categorized all cases where we were
      implicitly adding "| Undefined" to the field type, as follows:
      
      1. Classes that aren't using the generated verifier function (we should
         probably revisit these, but for now we at least know they're safe):
         - JSGlobalObject
         - JSFinalizationGroup
         - JSFinalizationGroupCleanupIterator
      
      2. Classes where the existing verifier is already at least as strict as
         what we would get after removing the implicit "| Undefined":
         - JSDate
         - JSPromise
         - JSRegExp
         - JSRegExpStringIterator
         - WasmMemoryObject
         - JSWeakRef
         - JSStringIterator
         - WasmExceptionObject
         - JSListFormat (fixed in part 1)
         - JSPluralRules (fixed in part 1)
         - JSRelativeTimeFormat (fixed in part 1)
         - JSSegmenter (fixed in part 1)
         - JSArrayBufferView (fixed in part 1)
         - JSTypedArray (fixed in part 1)
      
      3. Classes where, to the best of my knowledge based on code inspection,
         we already initialize the object correctly to pass the new stricter
         generated verifier:
         - JSFunction
         - JSArrayIterator
         - JSMessageObject
         - JSBoundFunction
         - JSAsyncFromSyncIterator
         - WasmModuleObject
         - JSAsyncFunctionObject
      
      4. Classes that needed some adjustment to their initialization order to
         avoid exposing uninitialized state to the GC:
         - JSArray (only in Factory::NewJSArray; Runtime_NewArray and
                    CodeStubAssembler::AllocateJSArray already behave fine)
         - WasmTableObject
         - JSDateTimeFormat
         - JSNumberFormat
         - JSCollator
         - JSV8BreakIterator
         - JSLocale
         - JSSegmentIterator
         - JSModuleNamespace
      
      5. Classes that had incorrect type definitions in Torque:
         - WasmGlobalObject (category 4 after correction)
      
      6. Classes that weren't fully initialized due to bugs:
         - JSGeneratorObject
         - JSAsyncGeneratorObject
      
      Bug: v8:9311
      Change-Id: I99ab303d3352423f50a3d0abb6eb0c9b463e7552
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1654980
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62228}
      15ea19db
  14. 23 May, 2019 3 commits
  15. 22 May, 2019 1 commit
  16. 17 May, 2019 1 commit
  17. 16 May, 2019 2 commits
  18. 15 May, 2019 1 commit
  19. 10 Apr, 2019 1 commit
  20. 08 Feb, 2019 1 commit
  21. 06 Feb, 2019 1 commit
    • Frank Tang's avatar
      [Intl] Sync Locale code to latest spec · f6d44ed4
      Frank Tang authored
      1. Change the function to align with UTS35 instead of (old) RFC.
      2. Restrict tag as Unicode Locale Identifier by code that on top of ICU.
      Because icu::Locale in ICU63 is not tight enough to restrict that.
      Added comments to show what to do (to use icu::LocaleBuilder) after
      the landing of ICU64
      3. Fix to pass two tests in test262.
      
      Bug: v8:8262,v8:8670,v8:7684
      Change-Id: If244647e6a50daae305b9ae1a569100859be8a0c
      Reviewed-on: https://chromium-review.googlesource.com/c/1435737
      Commit-Queue: Frank Tang <ftang@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59382}
      f6d44ed4
  22. 15 Jan, 2019 2 commits
  23. 10 Jan, 2019 1 commit
  24. 04 Jan, 2019 1 commit
  25. 03 Jan, 2019 1 commit
  26. 20 Dec, 2018 1 commit
  27. 17 Dec, 2018 1 commit
  28. 15 Dec, 2018 2 commits
  29. 27 Nov, 2018 1 commit
  30. 08 Nov, 2018 1 commit
  31. 06 Oct, 2018 2 commits
  32. 05 Oct, 2018 1 commit
    • Jungshik Shin's avatar
      Use ICU to validate and canonicalize lang tag · 2abb31a9
      Jungshik Shin authored
      - Get rid of an unnecessary call to uloc_canonicalize in js-locale.
      - Do not use regex, but rely on ICU for the structrural validity check
      with Chrome's ICU or ICU 63 or newer. Otherwise, continue to use regex.
      
      This became possible thanks to a couple of bug fixes in ICU ToT that
      were cherry-picked for Chromium's ICU.
      
      Not yet done is to change js-locale to use CanonicalizeLocale().
      That will make a few more tests pass.
      
      Bug: v8:8135
      Test: test262/intl402/Intl/getCanonicalLocales/*
      Test: test262/intl402/Locale/*
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: I45c10b298fb041e0b39a4d96309c68a7966f91c2
      Reviewed-on: https://chromium-review.googlesource.com/c/1215223
      Commit-Queue: Jungshik Shin <jshin@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56399}
      2abb31a9
  33. 04 Oct, 2018 2 commits