1. 02 May, 2017 1 commit
  2. 28 Apr, 2017 3 commits
  3. 21 Apr, 2017 1 commit
  4. 19 Apr, 2017 1 commit
    • Caitlin Potter's avatar
      [parser] avoid complex for-loop desugaring when possible · 267115da
      Caitlin Potter authored
      let/const declarations in "standard" C-style for-loops have
      some complex desugaring to accommodate the case where loop
      loop variables may be captured. This slows down the baseline
      performance of for-loops with let variables.
      
      This change attempts to avoid this desugaring if it's known that
      the loop variable is not captured at any point. A side effect of
      this change is that let/const loop variables, when not captured
      within the loop body, are not necessarily shown in the debugger,
      similar to other stack-allocated vars.
      
      BUG=v8:4762, v8:5460
      R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org
      
      Change-Id: I8dbe545a12c086f675972bdba60c94998268311a
      Reviewed-on: https://chromium-review.googlesource.com/472247
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44731}
      267115da
  5. 05 Apr, 2017 1 commit
  6. 04 Apr, 2017 1 commit
  7. 03 Apr, 2017 1 commit
  8. 29 Mar, 2017 2 commits
  9. 28 Mar, 2017 1 commit
  10. 27 Mar, 2017 1 commit
  11. 24 Mar, 2017 2 commits
  12. 22 Mar, 2017 1 commit
    • kozyatinskiy's avatar
      [debugger] tuned StepNext and StepOut at return position · e27d18c9
      kozyatinskiy authored
      Proposed behaviour:
      - StepNext at return position go into next function call (no changes with current behavior, but implemented in v8::Debug instead of hack on inspector side);
      - StepOut at return position go into next non-current function call.
      
      We need this to have better stepping in cases with native functions, blackboxed functions and/or different embedder calls (e.g. event listeners).
      
      New behavior could be illustrated with two examples (for more see stepping-with-natives-and-frameworks test):
      - let's assume that we've blackboxed callAll function, this function just takes its arguments and call one after another:
      var foo = () => 1;
      callAll(foo, foo, () => 2);
      If we break inside of first call of function foo. Then on..
      ..StepNext - we're able to reach second call of function foo,
      ..StepOut - we're able to reach () => 2 call.
      
      - let's consider case with native function:
      [1,2,3].map(x => x * 2)
      If we break inside of first callback call, then with StepNext we can iterate through all calls of callback, with StepOut we go to next statement after .map call.
      
      Implementation details:
      - when we request break we schedule step-in function call for any step action at return position and for step-in at any position,
      - when we request StepOut at return position - we mark current function as needed-to-be-ignored inside of PrepareStepIn(function) call,
      - when we request StepOut at not return position - we set break at return position and ask debugger to just repeat last step action on next stepping-related break.
      
      Design doc: https://docs.google.com/document/d/1ihXHOIhP_q-fJCA0e2EiXz_Zr3B08KMjaPifcaqZ60Q/edit
      
      BUG=v8:6118,chromium:583193
      R=dgozman@chromium.org,yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2758483002
      Cr-Commit-Position: refs/heads/master@{#44028}
      e27d18c9
  13. 18 Mar, 2017 1 commit
  14. 17 Mar, 2017 1 commit
    • littledan's avatar
      [intl] Fix debug-evaluate-no-side-effect-builtins test · 3fa26338
      littledan authored
      String case conversion is known to debug-evaluate to not have a side
      effect in noi18n mode, but debug-evaluate thinks it has a side effect
      in i18n mode. Update the tests accordingly.
      
      Verified locally that the test passes in i18n and noi18n mode (not sure
      whether the noi18n trybot executes this test).
      
      CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng
      
      Review-Url: https://codereview.chromium.org/2750403004
      Cr-Commit-Position: refs/heads/master@{#43882}
      3fa26338
  15. 16 Mar, 2017 1 commit
  16. 15 Mar, 2017 1 commit
  17. 13 Mar, 2017 3 commits
  18. 10 Mar, 2017 1 commit
  19. 07 Mar, 2017 1 commit
  20. 28 Feb, 2017 2 commits
  21. 22 Feb, 2017 2 commits
  22. 16 Feb, 2017 1 commit
    • jgruber's avatar
      [debug] Handle OOM events in debugger tests · e9f5e1e9
      jgruber authored
      Map OOM breaks generated by inspector to DebugEvent.OOM.
      This avoids generating unintentional DebugEvent.Break events.
      
      Also be more future-proof in event categorization.
      
      On a related note, this CL also fixes a DCHECK in
      Runtime::GetFrameDetails.
      
      The receiver needs to be grabbed from the inlined frame, not
      the outer optimized frame. Optimized frames only provide the
      receiver on a best-effort basis.
      
      BUG=v8:5950
      
      Review-Url: https://codereview.chromium.org/2696173002
      Cr-Commit-Position: refs/heads/master@{#43244}
      e9f5e1e9
  23. 13 Feb, 2017 1 commit
  24. 10 Feb, 2017 3 commits
  25. 09 Feb, 2017 4 commits
  26. 08 Feb, 2017 1 commit
  27. 04 Feb, 2017 1 commit