1. 09 Mar, 2020 1 commit
    • Dan Elphick's avatar
      [api] Create v8::String::NewFromLiteral that returns Local<String> · b097a8e5
      Dan Elphick authored
      String::NewFromLiteral is a templated function that takes a char[N]
      argument that can be used as an alternative to String::NewFromUtf8 and
      returns a Local<String> rather than a MaybeLocal<String> reducing the
      number of ToLocalChecked() or other checks.
      
      Since the string length is known at compile time, it can statically
      assert that the length is less than String::kMaxLength, which means that
      it can never fail at runtime.
      
      This also converts all found uses of NewFromUtf8 taking a string literal
      or a variable initialized from a string literal to use the new API. In
      some cases the types of stored string literals are changed from const
      char* to const char[] to ensure the size is retained.
      
      This API does introduce a small difference compared to NewFromUtf8. For
      a case like "abc\0def", NewFromUtf8 (using length -1 to infer length)
      would treat this as a 3 character string, whereas the new API will treat
      it as a 7 character string.
      
      As a drive-by fix, this also fixes all redundant uses of
      v8::NewStringType::kNormal when passed to any of the String::New*
      functions.
      
      Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarMathias Bynens <mathias@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66622}
      b097a8e5
  2. 24 May, 2019 1 commit
  3. 30 Apr, 2019 1 commit
  4. 08 Feb, 2019 1 commit
  5. 26 Nov, 2018 1 commit
    • Marja Hölttä's avatar
      [iwyu] Include heap-inl.h less. · 0453d418
      Marja Hölttä authored
      - Remove heap-inl.h includes from places where it looked unnecessary. (This is a
        non-scientific approach, because it's probably pulled in indirectly anyway.)
      
      - Annotate places which include heap-inl.h because they need heap/ internals.
      
      - ACCESSORS legitimately needs heap-inl.h because of Heap::FromWritableHeapObject.
      
      - Add includes to heap/heap-write-barrier(-inl).h
      
      - A bunch of IWYU fixes discovered when working on this CL (includes which were
        missing because heap-inl.h pulls them in indirectly).
      
      BUG=v8:7490,v8:8238,v8:8499
      
      Change-Id: I00f9a74d430f13d7c080dca77a92b03bcca7ef96
      Reviewed-on: https://chromium-review.googlesource.com/c/1349241Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57814}
      0453d418
  6. 17 Sep, 2018 1 commit
  7. 14 Sep, 2018 1 commit
  8. 13 Oct, 2017 1 commit
  9. 14 Aug, 2017 1 commit
  10. 15 Sep, 2016 1 commit
    • franzih's avatar
      [runtime] Intercept function declarations. · 8439401d
      franzih authored
      We used to intercept function definitions, but not declarations.
      GenericNamedPropertySetterCallback now also intercepts function declarations.
      
      For definitions, we call DeclareGlobal and then InitializeVarGlobal. For
      declarations, we never call InitializeVarGlobal, thus we must check for
      interceptors in DeclareGlobal.
      
      If the semantics of a redeclaration are wrong, e.g., redeclaring a read-only
      property, an exception is thrown independent of whether an interceptor is
      installed. Usually, i.e., not during a declaration, we only throw if
      the call is not successfully intercepted.
      
      BUG=v8:5375
      
      Review-Url: https://codereview.chromium.org/2334733002
      Cr-Commit-Position: refs/heads/master@{#39450}
      8439401d
  11. 07 Sep, 2016 1 commit
  12. 01 Sep, 2016 1 commit
  13. 10 Aug, 2016 1 commit
    • krasin's avatar
      cctest: put some types into anonymous namespace. · a9b5eb0c
      krasin authored
      This is to prevent a collision with Expectations class defined in test-field-type-tracking.cc, which happens in Clang under certain conditions (official build + Precise + unknown).
      
      While the original intent was to just workaround the Clang bug, putting types into anonymous namespace seems reasonable anyway (thank you to Benedikt Meurer for the suggestion!)
      
      BUG=630335
      
      Review-Url: https://codereview.chromium.org/2227073002
      Cr-Commit-Position: refs/heads/master@{#38552}
      a9b5eb0c
  14. 22 Mar, 2016 1 commit
    • adamk's avatar
      Remove support for legacy const, part 1 · ed18aa65
      adamk authored
      Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
      are no more. This lets us remove a bunch of code from many parts of the
      codebase.
      
      In this patch, I remove parser support for generating legacy const variables
      from const declarations. This also removes the special "illegal declaration"
      bit from Scope, which has ripples into all compiler backends.
      
      Also gone are any tests which relied on legacy const declarations.
      
      Note that we do still generate a Variable in mode CONST_LEGACY in one case:
      function name bindings in sloppy mode. The likely fix there is to add a new
      Variable::Kind for this case and handle it appropriately for stores in each
      backend, but I leave that for a later patch to make this one completely
      subtractive.
      
      Review URL: https://codereview.chromium.org/1819123002
      
      Cr-Commit-Position: refs/heads/master@{#35002}
      ed18aa65
  15. 11 Jan, 2016 1 commit
    • littledan's avatar
      Ship ES2015 sloppy-mode const semantics · 95145fa8
      littledan authored
      This patch moves the semantics of 'const' in sloppy mode to match those
      in strict mode, that is, const makes lexical (let-like) bindings, must
      have an initializer, and does not create properties of the global object.
      
      R=adamk
      LOG=Y
      BUG=v8:3305
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      
      Review URL: https://codereview.chromium.org/1571873004
      
      Cr-Commit-Position: refs/heads/master@{#33218}
      95145fa8
  16. 09 Dec, 2015 1 commit
  17. 07 Dec, 2015 1 commit
  18. 01 Jul, 2015 1 commit
    • verwaest's avatar
      Minor performance improvements to the LookupIterator · 5c278f63
      verwaest authored
      This change changes bootstrapping semantics for intercepted global objects. Unlike before, we'll now also call into the interceptor during bootstrapping. This affects properties loaded from within the runtime, such as global.Array and global.Symbol. The embedder will need to make sure that those values are the expected values during bootstrapping.
      
      BUG=chromium:505998
      LOG=n
      
      Review URL: https://codereview.chromium.org/1220813005
      
      Cr-Commit-Position: refs/heads/master@{#29414}
      5c278f63
  19. 28 May, 2015 1 commit
  20. 13 Mar, 2015 2 commits
  21. 23 Feb, 2015 1 commit
  22. 05 Feb, 2015 1 commit
  23. 30 Jan, 2015 3 commits
  24. 27 Jan, 2015 1 commit
    • adamk's avatar
      Begin modernization of --harmony-modules · aeb3a717
      adamk authored
      The approach taken in this CL is to incrementally move toward the
      currently-specced version of modules in ES6. The biggest change in this
      patch is separating the parsing of modules from the parsing of scripts,
      getting rid of the 'module' keyword and thus disallowing modules-in-scripts
      as well as modules-in-modules.
      
      The syntax supported by import/export declarations has not yet been significantly
      changed, with the major exception being that import declarations require a string
      as the 'from' part.
      
      Most of the existing tests have been disabled, with a first new test added
      in cctest/test-parsing.
      
      BUG=v8:1569
      LOG=n
      
      Review URL: https://codereview.chromium.org/881623002
      
      Cr-Commit-Position: refs/heads/master@{#26299}
      aeb3a717
  25. 27 Nov, 2014 1 commit
  26. 21 Nov, 2014 1 commit
  27. 12 Nov, 2014 1 commit
  28. 11 Nov, 2014 2 commits
  29. 10 Nov, 2014 1 commit
  30. 07 Nov, 2014 1 commit
    • dslomov@chromium.org's avatar
      harmony_scoping: Implement lexical bindings at top level · 1a64b02d
      dslomov@chromium.org authored
      This implements correct semantics for "extensible" top level lexical scope.
      The entire lexical scope is represented at runtime by GlobalContextTable, reachable from native context and accumulating global contexts from every script loaded into the context.
      
      When the new script starts executing, it does the following validation:
      - checks the GlobalContextTable and global object (non-configurable own) properties against the set of declarations it introduces and reports potential conflicts.
      - invalidates the conflicting PropertyCells on global object, so that any code depending on them will miss/deopt causing any contextual lookups to be reexecuted under the new bindings
      - adds the lexical bindings it introduces to the GlobalContextTable
      
      Loads and stores for contextual lookups are modified so that they check the GlobalContextTable before looking up properties on global object, thus implementing the shadowing of global object properties by lexical declarations.
      
      R=adamk@chromium.org, rossberg@chromium.org
      
      Review URL: https://codereview.chromium.org/705663004
      
      Cr-Commit-Position: refs/heads/master@{#25220}
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      1a64b02d
  31. 29 Oct, 2014 1 commit
  32. 05 Aug, 2014 1 commit
  33. 29 Jul, 2014 2 commits
  34. 18 Jul, 2014 1 commit
  35. 14 Jul, 2014 1 commit