1. 30 May, 2018 1 commit
  2. 17 May, 2018 1 commit
  3. 08 May, 2018 1 commit
  4. 26 Apr, 2018 1 commit
  5. 25 Apr, 2018 1 commit
  6. 11 Aug, 2017 1 commit
    • Michael Starzinger's avatar
      [test] Rebaseline inspector test. · f984eb1b
      Michael Starzinger authored
      This changes the baseline of an inspector test setting breakpoints
      within an asm.js module while the module is being executed. With the
      validator it is not supported to switch from active WebAssembly code
      back to debuggable interpreter code. Hence some previously expected
      breakpoints no longer fire, the behavior is consistent across all
      configurations now though.
      
      R=yangguo@chromium.org
      TEST=inspector/debugger/asm-js-breakpoint-during-exec
      BUG=v8:6166
      
      Change-Id: Ie1bb62fa6df28b10336b4cb5d381d2141eec356c
      Reviewed-on: https://chromium-review.googlesource.com/608977Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47301}
      f984eb1b
  7. 10 Aug, 2017 1 commit
  8. 27 Jul, 2017 1 commit
  9. 18 Jul, 2017 1 commit
  10. 14 Jul, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] improve return position of explicit return in non-async function · 08965860
      Alexey Kozyatinskiy authored
      Goal of this CL: explicit return from non-async function has position after
      return expression as return position (will unblock [1]).
      
      BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods.
      If one of these methods is called then next generated bytecode will get passed
      position. It's general treatment for most cases.
      Unfortunately it doesn't work for Returns:
      - debugger requires source positions exactly on kReturn bytecode in stepping
        implementation,
      - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn
        generates more then one bytecode and general solution will put return position
        on first generated bytecode,
      - it's not easy to split BuildReturn function into two parts to allow something
        like following in BytecodeGenerator::VisitReturnStatement since generated
        bytecodes are actually controlled by execution_control().
      ..->BuildReturnPrologue();
      ..->SetReturnPosition(stmt);
      ..->Return();
      
      In this CL we pass ReturnStatement through ExecutionControl and use it for
      position when we emit return bytecode right here.
      
      So this CL only will improve return position for returns inside of non-async
      functions, I'll address async functions later.
      
      [1] https://chromium-review.googlesource.com/c/543161/
      
      Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db
      Reviewed-on: https://chromium-review.googlesource.com/560738
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46687}
      08965860
  11. 14 Jun, 2017 1 commit
  12. 08 Jun, 2017 1 commit
  13. 05 May, 2017 1 commit
  14. 04 May, 2017 2 commits
  15. 03 Apr, 2017 2 commits
  16. 29 Mar, 2017 3 commits
  17. 28 Mar, 2017 1 commit
  18. 02 Mar, 2017 1 commit
  19. 25 Feb, 2017 1 commit
  20. 17 Nov, 2016 1 commit
  21. 02 Oct, 2016 1 commit
  22. 26 Jan, 2016 1 commit
  23. 19 Jan, 2016 1 commit
  24. 04 Jan, 2016 1 commit
    • machenbach's avatar
      [test] Add ignition test set. · ee665067
      machenbach authored
      Add control for the ignition test suites. This will be
      followed by a change on the infra side that targets the
      ignition set instead of the hardcoded mjsunit.
      
      After that, cctest can be enabled in a separate CL. This CL
      already includes the logic for running cctest for ignition
      on swarming.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1559943002
      
      Cr-Commit-Position: refs/heads/master@{#33089}
      ee665067
  25. 14 Oct, 2015 1 commit
  26. 06 Oct, 2015 1 commit
    • machenbach's avatar
      [swarming] Run unittests together with default tests. · 35d2028d
      machenbach authored
      This adds the unittests to the "default" test set. Now that
      the "default" and the DEFAULT_TESTS (i.e. runner with
      no arguments) are the same, removed DEFAULT_TESTS and use
      TEST_MAP["default"] instead.
      
      On the bots, where unittests and default were run in
      separation before, the explicit unittests step should now
      be skipped.
      
      This is necessary for swarming, as the unittests step is
      too small to justify its own swarming job.
      
      BUG=chromium:535160
      LOG=n
      
      Review URL: https://codereview.chromium.org/1374733006
      
      Cr-Commit-Position: refs/heads/master@{#31122}
      35d2028d
  27. 05 Oct, 2015 1 commit
  28. 25 Sep, 2015 1 commit