1. 25 Jan, 2022 1 commit
  2. 09 Nov, 2021 1 commit
    • Joyee Cheung's avatar
      [class] fix evaluation order and errors in private accessor assignments · f77b05d4
      Joyee Cheung authored
      In assignments the lhs should be evaluated first and shouldn't be
      re-evaluated when the value of the rhs is available. Fix it by
      saving the receiver and the key registers into AssignmentLhsData
      before building the assignment and use them later, instead of visiting
      the AST again to retrieve the receiver.
      
      In addition, now that we save the receiver register, use it to
      perform the brand check even when we know for sure that it's
      going to fail later because it's a write to a private
      method or accessing the accessor in the wrong way (v8:11364),
      so that the brand check error always appears first if it is present,
      as specified in
      https://tc39.es/proposal-private-methods/#sec-privatefieldget
      
      Drive-by: unify the brand check error messages, and replace "Object"
      with "Receiver" in the messages for clarity. The instance private
      brand check now throws "Receiver must be an instance of class <name>"
      and the static private brand check now throws "Receiver must be
      class <name>". Also always set the expression position to the
      property load position, because the brand check failure comes from
      the load operation.
      
      Bug: v8:12352, v8:11364
      Change-Id: I61a8979b2e02b561dd5b2b35f9e0b6691fe07599
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3266964
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77797}
      f77b05d4
  3. 02 Jun, 2021 1 commit
  4. 26 Jan, 2021 1 commit
  5. 27 Jun, 2019 1 commit
  6. 11 Apr, 2017 1 commit
    • gsathya's avatar
      [ESNext] Implement DynamicImportCall · 94283dcf
      gsathya authored
      This patch implements the runtime semantics of dynamic import.
      
      We create a new ASTNode so that we can pass the JSFunction closure() to
      the runtime function from which we get the script_url.
      
      d8 implements the embedder logic required to load and evaluate the modules.
      
      The API is mostly implemented as specified.
      
      BUG=8:5785
      
      Review-Url: https://codereview.chromium.org/2703563002
      Cr-Commit-Position: refs/heads/master@{#44551}
      94283dcf
  7. 28 Feb, 2017 1 commit
  8. 17 Feb, 2017 1 commit
    • vabr's avatar
      Report unexpected lexical decl also without destructuring · 454816f0
      vabr authored
      https://codereview.chromium.org/2694003002/ introduced
      "SyntaxError: Lexical declaration cannot appear in a single-statement context"
      for the case when let + desctructuring from a list happen.
      
      As was pointed out in https://codereview.chromium.org/2694003002/#msg18, the
      case without destructuring would also benefit from a better message: if a
      single statement is expected and "let identifier = ..." is seen, the error is
      indeed again that the lexical declaration is not a statement. However, the current
      error is "Unexpected identifier", because the parser tries to accept "let" as
      an identifier in an expression statement, and then gives up seeing the other
      identifier after "let".
      
      This CL ensures that the parser recognises the error properly and reports
      accordingly. It also renames the existing test, which contains destructuring,
      and adds the one with a non-destructuring lexical declaration.
      
      BUG=v8:5686
      
      Review-Url: https://codereview.chromium.org/2697193007
      Cr-Commit-Position: refs/heads/master@{#43275}
      454816f0
  9. 16 Feb, 2017 1 commit
  10. 16 Jan, 2017 1 commit
  11. 12 Jan, 2017 1 commit
  12. 04 Jan, 2017 1 commit