1. 10 Aug, 2016 1 commit
  2. 09 Aug, 2016 2 commits
  3. 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
  4. 01 Aug, 2016 1 commit
  5. 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
  6. 12 Jul, 2016 2 commits
  7. 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
  8. 08 Jul, 2016 1 commit
  9. 30 Jun, 2016 1 commit
  10. 24 Jun, 2016 1 commit
  11. 21 Jun, 2016 1 commit
  12. 31 May, 2016 2 commits
  13. 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
  14. 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
  15. 02 May, 2016 2 commits
  16. 29 Apr, 2016 1 commit
  17. 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
  18. 26 Apr, 2016 1 commit
  19. 21 Apr, 2016 2 commits
  20. 08 Apr, 2016 2 commits
  21. 04 Apr, 2016 1 commit
  22. 01 Apr, 2016 1 commit
    • littledan's avatar
      Revert of Remove RegExp.prototype.source getter compat workaround (patchset #2... · 31e806eb
      littledan authored
      Revert of Remove RegExp.prototype.source getter compat workaround (patchset #2 id:20001 of https://codereview.chromium.org/1837843002/ )
      
      Reason for revert:
      TC39 decided that this compatibility fix should be standardized.
      
      Original issue's description:
      > Remove RegExp.prototype.source getter compat workaround
      >
      > The getter RegExp.prototype.source is specified in ES2015 to throw when
      > called on a non-RegExp instance, such as RegExp.prototype. We had previously
      > put in a compatibility workaround for all RegExp getters to make them
      > throw on access specifically with RegExp.prototype as the receiver; however,
      > we only have evidence that this is needed for properties other than source.
      > This patch removes the compatibility workaround for get RegExp.prototype.source
      > and gives it semantics precisely as per the ES2015 specification.
      >
      > R=adamk
      > BUG=chromium:581577,v8:4827
      > LOG=Y
      >
      > Committed: https://crrev.com/80803aa89e31839b8f73959776fa7e1923c6b461
      > Cr-Commit-Position: refs/heads/master@{#35086}
      
      R=adamk@chromium.org
      # Not skipping CQ checks because original CL landed more than 1 days ago.
      BUG=chromium:581577,v8:4827
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1847783003
      
      Cr-Commit-Position: refs/heads/master@{#35180}
      31e806eb
  23. 28 Mar, 2016 1 commit
    • littledan's avatar
      Remove RegExp.prototype.source getter compat workaround · 80803aa8
      littledan authored
      The getter RegExp.prototype.source is specified in ES2015 to throw when
      called on a non-RegExp instance, such as RegExp.prototype. We had previously
      put in a compatibility workaround for all RegExp getters to make them
      throw on access specifically with RegExp.prototype as the receiver; however,
      we only have evidence that this is needed for properties other than source.
      This patch removes the compatibility workaround for get RegExp.prototype.source
      and gives it semantics precisely as per the ES2015 specification.
      
      R=adamk
      BUG=chromium:581577,v8:4827
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1837843002
      
      Cr-Commit-Position: refs/heads/master@{#35086}
      80803aa8
  24. 22 Mar, 2016 2 commits
    • adamk's avatar
      Remove support for legacy const, part 1 · ed18aa65
      adamk authored
      Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
      are no more. This lets us remove a bunch of code from many parts of the
      codebase.
      
      In this patch, I remove parser support for generating legacy const variables
      from const declarations. This also removes the special "illegal declaration"
      bit from Scope, which has ripples into all compiler backends.
      
      Also gone are any tests which relied on legacy const declarations.
      
      Note that we do still generate a Variable in mode CONST_LEGACY in one case:
      function name bindings in sloppy mode. The likely fix there is to add a new
      Variable::Kind for this case and handle it appropriately for stores in each
      backend, but I leave that for a later patch to make this one completely
      subtractive.
      
      Review URL: https://codereview.chromium.org/1819123002
      
      Cr-Commit-Position: refs/heads/master@{#35002}
      ed18aa65
    • mythria's avatar
      [Interpreter] Fixes CopyBytecodeArray to copy interrupt_budget field. · 27338320
      mythria authored
      Fixes CopyBytecodeArray to set the interrupt_budget field.
      
      BUG=v8:4280,v8:4690
      LOG=N
      
      Review URL: https://codereview.chromium.org/1809123003
      
      Cr-Commit-Position: refs/heads/master@{#34982}
      27338320
  25. 21 Mar, 2016 1 commit
  26. 18 Mar, 2016 1 commit
  27. 16 Mar, 2016 1 commit
    • littledan's avatar
      Ship ES2015 restrictions on function declaration locations · f9db79eb
      littledan authored
      Function declarations were previously permitted by V8 in many locations
      which no ECMAScript specification allowed; the ECMAScript 2015 spec
      enumerates a few locations (in blocks, as well as after labels and in
      conditionals when in sloppy mode). This patch ships the flag to restrict
      the usage of function declarations to those contexts.
      
      R=adamk
      LOG=Y
      BUG=v8:4824
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      
      Review URL: https://codereview.chromium.org/1799233003
      
      Cr-Commit-Position: refs/heads/master@{#34828}
      f9db79eb
  28. 15 Mar, 2016 2 commits
  29. 14 Mar, 2016 2 commits
    • littledan's avatar
      Make test262 test runner check for which exception is thrown · f3568ca4
      littledan authored
      test262 "negative" test expectations list which exception is thrown. The ES2017
      draft specification is very specific about which exception class is thrown
      from which path, and V8 works hard to be correct with respect to that spec.
      
      Previously, the test262 test runner would accept any nonzero status code,
      such as from a crash, or a FAIL printed out, for a negative test. This
      patch makes negative tests check for the right answer using a quick-and-dirty
      parsing of the exception printing from d8 to find the exception class.
      It invokes d8 in a way to get a status code of 0 from thrown exceptions
      so that 'negative' tests aren't actually implemented by negating the output.
      
      Amazingly, this didn't catch any test262 failures, but I verified the extra
      checking interactively by changing a negative test to expect a different type
      and saw it fail.
      
      BUG=v8:4803
      R=machenbach
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1766503002
      
      Cr-Commit-Position: refs/heads/master@{#34763}
      f3568ca4
    • mstarzinger's avatar
      [interpreter] Fix label binding for unreached labels. · 27a9009a
      mstarzinger authored
      This fixes the label binding mechanism that forwards a label to another
      already bound target label. For source labels that are not being reached
      by a jump, we should not try to patch jump sites. We still bind the
      source label to reflect the target position though, just in case this
      binding method will be used for backwards branches in the future.
      
      R=rmcilroy@chromium.org
      TEST=webkit/fast/js/parser-syntax-check
      
      Review URL: https://codereview.chromium.org/1804643002
      
      Cr-Commit-Position: refs/heads/master@{#34759}
      27a9009a