1. 28 Mar, 2017 3 commits
    • jgruber's avatar
      [regexp] Named capture support for string replacements · 9403edfa
      jgruber authored
      This implements support for named captures in
      RegExp.prototype[@@replace] for when the replaceValue is not callable.
      
      Named captures can be referenced from replacement strings by using the
      "$<name>" syntax. A couple of examples:
      
      let re = /(?<fst>.)(?<snd>.)/u;
      "abcd".replace(re, "$<snd>$<fst>")  // "bacd"
      "abcd".replace(re, "$2$1")     // "bacd" (numbered refs work as always)
      "abcd".replace(re, "$<snd")    // SyntaxError (unterminated named ref)
      "abcd".replace(re, "$<42$1>")  // "cd" (invalid name)
      "abcd".replace(re, "$<thd>")   // "cd" (non-existent name)
      "abcd".replace(/(?<fst>.)|(?<snd>.)/u, "$<snd>")  // "cd" (non-matched capture)
      
      Support is currently behind the --harmony-regexp-named-captures flag.
      
      BUG=v8:5437
      
      Review-Url: https://codereview.chromium.org/2775303002
      Cr-Original-Commit-Position: refs/heads/master@{#44171}
      Committed: https://chromium.googlesource.com/v8/v8/+/17f13863b64b25eccf565e0aa9c4c441f0562b84
      Review-Url: https://codereview.chromium.org/2775303002
      Cr-Commit-Position: refs/heads/master@{#44182}
      9403edfa
    • jgruber's avatar
      Revert of [regexp] Named capture support for string replacements (patchset #5... · 34ffdd62
      jgruber authored
      Revert of [regexp] Named capture support for string replacements (patchset #5 id:80001 of https://codereview.chromium.org/2775303002/ )
      
      Reason for revert:
      Invalid DCHECKs for non-matched groups.
      
      Original issue's description:
      > [regexp] Named capture support for string replacements
      >
      > This implements support for named captures in
      > RegExp.prototype[@@replace] for when the replaceValue is not callable.
      >
      > Named captures can be referenced from replacement strings by using the
      > "$<name>" syntax. A couple of examples:
      >
      > let re = /(?<fst>.)(?<snd>.)/u;
      > "abcd".replace(re, "$<snd>$<fst>")  // "bacd"
      > "abcd".replace(re, "$2$1")     // "bacd" (numbered refs work as always)
      > "abcd".replace(re, "$<snd")    // SyntaxError (unterminated named ref)
      > "abcd".replace(re, "$<42$1>")  // "cd" (invalid name)
      > "abcd".replace(re, "$<thd>")   // "cd" (non-existent name)
      > "abcd".replace(/(?<fst>.)|(?<snd>.)/u, "$<snd>")  // "cd" (non-matched capture)
      >
      > Support is currently behind the --harmony-regexp-named-captures flag.
      >
      > BUG=v8:5437
      >
      > Review-Url: https://codereview.chromium.org/2775303002
      > Cr-Commit-Position: refs/heads/master@{#44171}
      > Committed: https://chromium.googlesource.com/v8/v8/+/17f13863b64b25eccf565e0aa9c4c441f0562b84
      
      TBR=yangguo@chromium.org,littledan@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5437
      
      Review-Url: https://codereview.chromium.org/2776293003
      Cr-Commit-Position: refs/heads/master@{#44180}
      34ffdd62
    • jgruber's avatar
      [regexp] Named capture support for string replacements · 17f13863
      jgruber authored
      This implements support for named captures in
      RegExp.prototype[@@replace] for when the replaceValue is not callable.
      
      Named captures can be referenced from replacement strings by using the
      "$<name>" syntax. A couple of examples:
      
      let re = /(?<fst>.)(?<snd>.)/u;
      "abcd".replace(re, "$<snd>$<fst>")  // "bacd"
      "abcd".replace(re, "$2$1")     // "bacd" (numbered refs work as always)
      "abcd".replace(re, "$<snd")    // SyntaxError (unterminated named ref)
      "abcd".replace(re, "$<42$1>")  // "cd" (invalid name)
      "abcd".replace(re, "$<thd>")   // "cd" (non-existent name)
      "abcd".replace(/(?<fst>.)|(?<snd>.)/u, "$<snd>")  // "cd" (non-matched capture)
      
      Support is currently behind the --harmony-regexp-named-captures flag.
      
      BUG=v8:5437
      
      Review-Url: https://codereview.chromium.org/2775303002
      Cr-Commit-Position: refs/heads/master@{#44171}
      17f13863
  2. 27 Mar, 2017 1 commit
  3. 23 Mar, 2017 1 commit
  4. 22 Mar, 2017 2 commits
  5. 15 Mar, 2017 1 commit
  6. 09 Mar, 2017 1 commit
  7. 07 Mar, 2017 1 commit
  8. 28 Feb, 2017 2 commits
  9. 24 Feb, 2017 1 commit
  10. 20 Feb, 2017 1 commit
  11. 17 Feb, 2017 2 commits
  12. 14 Feb, 2017 1 commit
  13. 13 Feb, 2017 4 commits
  14. 07 Feb, 2017 3 commits
  15. 01 Feb, 2017 2 commits
  16. 30 Jan, 2017 1 commit
    • mvstanton's avatar
      [TypeFeedbackVector] Combine the literals array and the feedback vector. · 93f05b64
      mvstanton authored
      They have the same lifetime. It's a match!
      
      Both structures are native context dependent and dealt with (creation,
      clearing, gathering feedback) at the same time. By treating the spaces used
      for literal boilerplates as feedback vector slots, we no longer have to keep
      track of the materialized literal count elsewhere.
      
      A follow-on CL removes even more parser infrastructure related to this count.
      
      BUG=v8:5456
      
      Review-Url: https://codereview.chromium.org/2655853010
      Cr-Commit-Position: refs/heads/master@{#42771}
      93f05b64
  17. 25 Jan, 2017 1 commit
  18. 24 Jan, 2017 2 commits
  19. 23 Jan, 2017 2 commits
  20. 18 Jan, 2017 4 commits
  21. 17 Jan, 2017 1 commit
    • neis's avatar
      [generators] Always call function with closure context when resuming. · c5948b98
      neis authored
      The resume trampolin used to call the generator function with the context of the
      last suspension rather than the closure's context.  While that was fine for
      Ignition, Turbofan got utterly confused.  With this CL, the resume trampolin
      always passes in the closure's context (like in the very first call of the
      generator function).  The generator function itself then restores its previously
      current context by reading it from the generator object and doing a
      PushContext.
      
      BUG=chromium:681171
      
      Review-Url: https://codereview.chromium.org/2639533002
      Cr-Commit-Position: refs/heads/master@{#42407}
      c5948b98
  22. 11 Jan, 2017 1 commit
  23. 10 Jan, 2017 1 commit
  24. 09 Jan, 2017 1 commit