1. 16 Apr, 2019 1 commit
    • Simon Zünd's avatar
      [stack-trace] Use ErrorStack accessor for formatted stack traces · c8206043
      Simon Zünd authored
      When a stack trace is captured, it is stored in a private symbol on
      the respective Error object. The first access to "Error.stack"  will
      then format the stack trace, with a possible call into user JS via
      the Error.prepareStackTrace callback.
      
      Until now, the accessor converted ".stack" to a normal data
      property containing the formatted stack trace. This causes a new Map
      with a new DescriptorArray to be created, which will not be shared
      with anything else (also not other error objects with formated
      stack traces).
      
      This CL changes the accessor to store the formatted stack trace in
      the same symbol (stack_trace_symbol) as the structured data. The
      result is that an error object will have the same Map before and
      after "Error.stack" is accessed.
      
      Bug: v8:9115
      Change-Id: I7d6bf49be76d63b57fbbaf904cc6ed7dbdbfb96b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564061
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60865}
      c8206043
  2. 18 Jul, 2017 1 commit
  3. 24 Apr, 2017 1 commit
  4. 05 Dec, 2016 1 commit
  5. 04 Aug, 2016 1 commit
  6. 02 Aug, 2016 1 commit
  7. 01 Aug, 2016 1 commit
  8. 29 Jul, 2016 1 commit
    • jgruber's avatar
      Set Error.stack property writable · 1c7c0521
      jgruber authored
      Previously, the stack property was set up in JS as read-only; but since
      it had a JS setter, writability was ignored and writing to stack was
      possible.
      
      This is no longer the case now that stack is either an actual data
      property, or is associated with C++ accessors. Explicitly set the
      property as writable to preserve old behavior.
      
      BUG=5245
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2190313002
      Cr-Commit-Position: refs/heads/master@{#38158}
      1c7c0521
  9. 28 Jul, 2016 2 commits
  10. 25 Jul, 2016 1 commit
  11. 22 Jul, 2016 1 commit
  12. 20 Jul, 2016 1 commit
  13. 03 Feb, 2016 1 commit
  14. 13 Jan, 2016 1 commit
    • bmeurer's avatar
      [builtins] Migrate Number constructor similar to String constructor. · 322ffda3
      bmeurer authored
      Also migrate the Number constructor to a native builtin, using the
      same mechanism already used by the String constructor. Otherwise just
      parsing and compiling the Number constructor to optimized code already
      eats 2ms on desktop for no good reason, and the resulting optimized
      code is not even close to awesome.
      
      Drive-by-fix: Use correct context for the [[Construct]] case of the
      String constructor as well, and share some code with it.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1573243009
      
      Cr-Commit-Position: refs/heads/master@{#33265}
      322ffda3
  15. 05 Jan, 2016 1 commit
    • bmeurer's avatar
      [runtime] Migrate several Date builtins to C++. · 065e9c53
      bmeurer authored
      Almost all of the Date builtins always call into C++ at least once
      anyway, so parsing, compiling and executing the JavaScript wrappers
      is just a waste of time.  The most important part here is the Date
      constructor itself, which is one of the blockers for new.target in
      TurboFan, because compiling the Date constructor takes too much time
      with TurboFan (for no reason since we end up in C++ anway).
      
      R=cbruni@chromium.org
      
      Review URL: https://codereview.chromium.org/1556333002
      
      Cr-Commit-Position: refs/heads/master@{#33109}
      065e9c53
  16. 09 Dec, 2015 3 commits
  17. 02 Dec, 2015 1 commit
  18. 25 Nov, 2015 2 commits
  19. 13 Mar, 2015 1 commit
  20. 02 Jul, 2014 1 commit
  21. 30 Jun, 2014 2 commits
  22. 26 Jul, 2013 1 commit
  23. 29 May, 2013 1 commit
  24. 14 Jan, 2013 1 commit
  25. 27 Dec, 2012 1 commit
  26. 20 Dec, 2012 1 commit
  27. 11 Dec, 2012 1 commit
  28. 24 May, 2012 1 commit
  29. 20 Oct, 2011 1 commit
  30. 20 Sep, 2010 1 commit
  31. 14 Aug, 2009 1 commit
  32. 27 Jul, 2009 1 commit
  33. 02 Jul, 2009 2 commits
  34. 30 Jun, 2009 1 commit
    • christian.plesner.hansen@gmail.com's avatar
      When Error.collectStackTraces is set to true all new instances of · 118a2ccc
      christian.plesner.hansen@gmail.com authored
      Error, ReferenceError, etc. are given a stack property that gives a
      stack trace.  Here's an example stack trace:
      
      ReferenceError: FAIL is not defined
          at Constraint.execute (deltablue.js:527)
          at Constraint.recalculate (deltablue.js:426)
          at Planner.addPropagate (deltablue.js:703)
          at Constraint.satisfy (deltablue.js:186)
          at Planner.incrementalAdd (deltablue.js:593)
          at Constraint.addConstraint (deltablue.js:164)
          at Constraint.BinaryConstraint (deltablue.js:348)
          at Constraint.EqualityConstraint (deltablue.js:517)
          at chainTest (deltablue.js:809)
          at deltaBlue (deltablue.js:881)
          at deltablue.js:888
      
      If Error.prepareStackTrace holds a function this function is used to
      format the stack trace, for instance allowing code generators to
      customize the way stack traces are reported to make them easier to
      process.
      
      Next step: performance measurements to see if it is feasible to turn
      this on by default.
      
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@2302 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      118a2ccc