1. 01 Jun, 2015 1 commit
  2. 29 May, 2015 1 commit
  3. 27 May, 2015 1 commit
    • vogelheim's avatar
      Fix DCHECK on SetBookmark. · 21e6831e
      vogelheim authored
      The DCHECK was a lie. The idea was that - when a bookmark is set -
      the scanner must clearly be at a character boundary and hence the
      bookmark does not need to save a 'partial' UTF-8 code point. The
      first part is true - the Scanner is always at a character boundary -
      but the 'partial' UTF-8 code point is at the end of a block, not at
      the current character position of the Scanner.
      Hence, the 'partial' character needs to be saved as well.
      
      jkummerow: Thanks for noticing.
      
      BUG=chromium:470930
      R=jochen@chromium.org, jkummerow@chromium.org
      LOG=N
      
      Review URL: https://codereview.chromium.org/1154773004
      
      Cr-Commit-Position: refs/heads/master@{#28661}
      21e6831e
  4. 26 May, 2015 1 commit
  5. 06 May, 2015 1 commit
  6. 05 Feb, 2015 1 commit
  7. 20 Oct, 2014 1 commit
    • marja@chromium.org's avatar
      Script streaming: more UTF-8 handing fixes (again). · 394af55a
      marja@chromium.org authored
      1) Since we fill the output buffer both from the chunks and the conversion
      buffer, it's possible that we run out of space and call CopyCharsHelper with 0
      length. The underlying functions don't handle it gracefully, so check there.
      
      2) There was a bug where we used to try to copy too many characters from the
      beginning of the data chunk into the conversion buffer. Continuation bytes in
      UTF-8 are of the form 0b10XXXXXX. If a byte is bigger than that, it's the first
      byte of a new UTF-8 character and we should ignore it.
      
      These two together (or maybe in combination with surrogates) are a probable
      reason for crbug.com/420932.
      
      3) The test data was off; \uc481 is \xec\x92\x81.
      
      BUG=420932
      LOG=N
      R=yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/662003003
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24725 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      394af55a
  8. 13 Oct, 2014 1 commit
  9. 26 Sep, 2014 1 commit
  10. 12 Sep, 2014 1 commit
  11. 11 Sep, 2014 2 commits
  12. 04 Aug, 2014 1 commit
  13. 09 Jul, 2014 1 commit
  14. 03 Jun, 2014 1 commit
  15. 29 Apr, 2014 1 commit
  16. 28 Mar, 2014 1 commit
  17. 06 Dec, 2013 1 commit
  18. 05 Jul, 2013 1 commit
  19. 12 Mar, 2012 1 commit
  20. 12 Sep, 2011 1 commit
  21. 08 Sep, 2011 1 commit
  22. 23 Aug, 2011 1 commit
  23. 22 Jun, 2011 1 commit
  24. 21 Jun, 2011 1 commit
  25. 24 May, 2011 1 commit
    • ricow@chromium.org's avatar
      Create stand-alone json parser (including scanner). · 3c7e1d70
      ricow@chromium.org authored
      The current json parser and scanner inherits fromt he normal scanners and parsers,
      which are more complicated than we need for parsing json.
      
      The supplied scanner works directly on the string supplied and has a
      fast case mode for scanning only ascii characters (it will simply
      create a substring or a symbol directly from the existing string). To
      allow for creating symbols from a substring I have added a
      SubStringAsciiSymbolKey that creates the hash based from our string
      without extracting the sub-string. In case we need to add the symbol
      it simply creates the symbol directly from the characters inside the
      given string.
      Review URL: http://codereview.chromium.org/7039037
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8029 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      3c7e1d70
  26. 12 Apr, 2011 1 commit
  27. 29 Mar, 2011 1 commit
  28. 18 Mar, 2011 3 commits
  29. 09 Feb, 2011 1 commit
  30. 07 Feb, 2011 1 commit
  31. 14 Jan, 2011 1 commit
  32. 03 Jan, 2011 1 commit
  33. 22 Dec, 2010 1 commit
  34. 07 Dec, 2010 1 commit
  35. 29 Nov, 2010 1 commit
  36. 19 Nov, 2010 1 commit
  37. 18 Nov, 2010 1 commit