1. 30 Nov, 2016 1 commit
  2. 24 Nov, 2016 1 commit
  3. 18 Nov, 2016 1 commit
    • marja's avatar
      Remove FLAG_min_preparse_length. · 4a5b7e32
      marja authored
      It originates from the era where we used to run a separate preparse step
      before parsing and store the function data. Now the usage of preparser
      is something completely different, so this flag doesn't make sense any
      more.
      
      In addition, this way we get more test coverage for preparser (for small
      scripts).
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2513563002
      Cr-Commit-Position: refs/heads/master@{#41110}
      4a5b7e32
  4. 17 Nov, 2016 1 commit
  5. 04 Nov, 2016 2 commits
  6. 19 Sep, 2016 1 commit
  7. 15 Sep, 2016 1 commit
  8. 29 Aug, 2016 1 commit
    • bgeron's avatar
      [turbofan] Also inline into try blocks. · 791118fc
      bgeron authored
      This removes test/webkit/fast/js/stack-overflow-arrity-catch.js, which tests that the stack overflows in a very particular way. It doesn't seem to test anything important, and only used to work because we didn't inline into try-blocks.
      
      BUG=
      R=jarin
      
      Review-Url: https://codereview.chromium.org/2216353002
      Cr-Commit-Position: refs/heads/master@{#38976}
      791118fc
  9. 22 Aug, 2016 2 commits
  10. 17 Aug, 2016 1 commit
  11. 10 Aug, 2016 1 commit
  12. 09 Aug, 2016 2 commits
  13. 04 Aug, 2016 1 commit
    • machenbach's avatar
      [test] Enable test status filtering by variant · 03f51248
      machenbach authored
      This adds the possibility to address test cases in the
      status file with the variant under which the test is running.
      This is only allowed in top-level sections.
      
      Example:
      [{
        'test-case': [PASS, SLOW],
      }]
      
      ['variant == foo', {
        'test-case': [FAIL],
      }]
      
      The test case "test-case" is marked as slow in all variants.
      Additionally, in variant foo, it'll be expected to fail.
      
      This CL also exemplifies the new feature with test cases
      running under the ignition_turbofan variant. The
      corresponding legacy flag is deprecated.
      
      BUG=v8:5238
      
      Review-Url: https://codereview.chromium.org/2203013002
      Cr-Commit-Position: refs/heads/master@{#38342}
      03f51248
  14. 01 Aug, 2016 1 commit
  15. 22 Jul, 2016 1 commit
    • jwolfe's avatar
      Adjust whitespace to make tests oblivious to --harmony-function-tostring · 3cfd80d6
      jwolfe authored
      See discussion in https://codereview.chromium.org/2156303002/#msg8
      
      With the new --harmony-function-tostring behavior, these tests would
      fail without this change. This change makes the tests pass regardless
      of whether or not --harmony-function-tostring is used.
      
      All of these changes are simply inserting a space after the "function"
      keyword to match the current function toString behavior. When
      --harmony-function-tostring is enabled, the toString behavior matches
      the spacing used in the function declaration. With the declaration
      matching the current formatting, the toString behavior becomes
      unaffected by --harmony-function-tostring.
      
      BUG=v8:4958
      LOG=n
      
      Review-Url: https://codereview.chromium.org/2161413002
      Cr-Commit-Position: refs/heads/master@{#37959}
      3cfd80d6
  16. 12 Jul, 2016 2 commits
  17. 11 Jul, 2016 1 commit
    • jwolfe's avatar
      Recognize HTMLCloseComment after multiline comment · b8668fa8
      jwolfe authored
      When the scanner finds a '-->', it's either part of an HTMLCloseComment
      or a '--' followed by a '>'. Previously, only a preceding newline would
      make it an HTMLCloseComment. Now, a preceding multiline comment also
      makes it an HTMLCloseComment. The effect is that now the following is
      not a SyntaxError:
      
      x/*
      */-->this is now a comment
      
      BUG=v8:5142
      LOG=y
      
      Review-Url: https://codereview.chromium.org/2119763003
      Cr-Commit-Position: refs/heads/master@{#37656}
      b8668fa8
  18. 08 Jul, 2016 1 commit
  19. 30 Jun, 2016 1 commit
  20. 24 Jun, 2016 1 commit
  21. 21 Jun, 2016 1 commit
  22. 31 May, 2016 2 commits
  23. 27 May, 2016 1 commit
    • littledan's avatar
      Unship ES2015 for-in initializer restrictions · 7245dabd
      littledan authored
      We now have data that 0.011% of websites use the pattern
        for (var i = 0 in j) { ... }
      This pattern was banned by ES2015, with the idea to revisit if
      it presents a web compatibility problem. Informally, after
      the May 2016 TC39 meeting, the new data was discussed, and there
      was interest in reversing the decision. Although the specification
      is not yet updated, it seems likely to come soon.
      
      This patch turns off the flag which bans that construct, reenabling
      it. The change should prevent websites from breaking.
      
      BUG=v8:4942
      
      Review-Url: https://codereview.chromium.org/2011223003
      Cr-Commit-Position: refs/heads/master@{#36562}
      7245dabd
  24. 11 May, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Fix incorrect frame walking in arguments create stubs · 40f34541
      rmcilroy authored
      The previous approach taken by FastNew[Sloppy,Strict,Rest]ArgumentsStub
      looked at the function slot in order to skip stub frames
      and find the JS frame. However, stub frames do not have a
      function slot (in fact their fixed frame ends one slot
      before the JS frame's function slot). Therefore, if this
      location in the stub frame happens to have the function
      object the create arguments stubs won't skip this frame
      correctly.
      
      Replace this approach with one where the stub is
      specialized to either skip a frame if required (since
      there will only ever be one extra frame on Ignition
      the loop approach isn't necessary).
      
      BUG=v8:4928
      LOG=N
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_dbg
      
      Review-Url: https://codereview.chromium.org/1949023003
      Cr-Commit-Position: refs/heads/master@{#36181}
      40f34541
  25. 02 May, 2016 2 commits
  26. 29 Apr, 2016 1 commit
  27. 28 Apr, 2016 3 commits
    • machenbach's avatar
      Revert of [Ignition] Test ignition on all bots. (patchset #4 id:60001 of... · af419971
      machenbach authored
      Revert of [Ignition] Test ignition on all bots. (patchset #4 id:60001 of https://codereview.chromium.org/1804003002/ )
      
      Reason for revert:
      Will resubmit with proper fix and more test skips.
      
      Original issue's description:
      > [Ignition] Test ignition on all bots.
      >
      > This adds ignition to the testing variants that are run on all
      > bots.
      >
      > Failing tests can only be skipped with the NO_IGNITION
      > keyword in status files. Existing expectations for the
      > ignition_turbofan variant are all duplicated and use the
      > NO_IGNITION keyword as well now.
      >
      > BUG=v8:4280
      > LOG=N
      > NOTRY=true
      
      TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,yangguo@chromium.org,mythria@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/1930943002
      Cr-Commit-Position: refs/heads/master@{#35871}
      af419971
    • rossberg's avatar
      Ship for-in initializer deprecation · 9e7793ea
      rossberg authored
      R=hablich@chromium.org
      BUG=v8:4942
      LOG=true
      
      Review-Url: https://codereview.chromium.org/1928513004
      Cr-Commit-Position: refs/heads/master@{#35868}
      9e7793ea
    • machenbach's avatar
      [Ignition] Test ignition on all bots. · 132c09ed
      machenbach authored
      This adds ignition to the testing variants that are run on all
      bots.
      
      Failing tests can only be skipped with the NO_IGNITION
      keyword in status files. Existing expectations for the
      ignition_turbofan variant are all duplicated and use the
      NO_IGNITION keyword as well now.
      
      BUG=v8:4280
      LOG=N
      NOTRY=true
      
      Review-Url: https://codereview.chromium.org/1804003002
      Cr-Commit-Position: refs/heads/master@{#35865}
      132c09ed
  28. 26 Apr, 2016 1 commit
  29. 21 Apr, 2016 2 commits
  30. 08 Apr, 2016 2 commits