1. 22 Jun, 2017 1 commit
    • Daniel Ehrenberg's avatar
      [scopes] Fix sloppy-mode block-scoped function hoisting edge case · d54ffadf
      Daniel Ehrenberg authored
      In edge cases such as the following, sloppy-mode block-scoped function
      hoisting is expected to occur:
      
        eval(`
          with({a: 1}) {
            function a() {}
          }
        `)
      
      In this case, there should be the equivalent of a var declaration
      outside of the eval, which gets set to the value of the local function
      a when the body of the with is executed.
      
      Previously, the way that var declarations are hoisted out of eval
      meant that the assignment to that var was an ordinary DYNAMIC_GLOBAL
      assignment. However, such a lookup mode meant that the object in the
      with scope received the assignment!
      
      This patch fixes that error by marking the assignments produced by
      the sloppy mode block scoped function hoisting desugaring so as to
      generate a different runtime call which skips with scopes.
      
      Bug: chromium:720247, v8:5135
      Change-Id: Ie36322ddc9ca848bf680163e8c016f50d4597748
      Reviewed-on: https://chromium-review.googlesource.com/529230
      Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46116}
      d54ffadf
  2. 24 Apr, 2017 1 commit
  3. 11 Apr, 2017 1 commit
    • Caitlin Potter's avatar
      [prettyprinter] improve call-printing of GetIterator nodes · b086856f
      Caitlin Potter authored
      Fix error message printed by Runtime_ThrowCalledNonCallable.
      
      As noted on the bug, this has a slight problem in that it will always
      print that "asyncIterator" was not callable for GetIterator with an
      async IteratorType, though it may be referring to a different call.
      This issue is present regardless of the change I introduced to perform
      this desugaring in the BytecodeGenerator.
      
      BUG=v8:6187
      R=adamk@chromium.org, verwaest@chromium.org
      
      Change-Id: I2077b7cd5976d9d9ba044f0dff44ee8c312d1263
      Reviewed-on: https://chromium-review.googlesource.com/470806Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#44543}
      b086856f
  4. 28 Feb, 2017 1 commit
  5. 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
  6. 16 Feb, 2017 1 commit
  7. 16 Jan, 2017 1 commit
  8. 12 Jan, 2017 1 commit
  9. 04 Jan, 2017 1 commit