1. 16 Sep, 2016 1 commit
  2. 15 Sep, 2016 1 commit
    • franzih's avatar
      [runtime] Intercept function declarations. · 8439401d
      franzih authored
      We used to intercept function definitions, but not declarations.
      GenericNamedPropertySetterCallback now also intercepts function declarations.
      
      For definitions, we call DeclareGlobal and then InitializeVarGlobal. For
      declarations, we never call InitializeVarGlobal, thus we must check for
      interceptors in DeclareGlobal.
      
      If the semantics of a redeclaration are wrong, e.g., redeclaring a read-only
      property, an exception is thrown independent of whether an interceptor is
      installed. Usually, i.e., not during a declaration, we only throw if
      the call is not successfully intercepted.
      
      BUG=v8:5375
      
      Review-Url: https://codereview.chromium.org/2334733002
      Cr-Commit-Position: refs/heads/master@{#39450}
      8439401d
  3. 12 Sep, 2016 3 commits
  4. 06 Sep, 2016 1 commit
  5. 05 Sep, 2016 1 commit
    • jochen's avatar
      Store the scope info in catch contexts · 9b6ff3a8
      jochen authored
      Since the extension field is already used for the catch name, store a
      ContextExtension there instead.
      
      In the future, this will allow for chaining ScopeInfos together, so we
      no longer need a context chain for lazy parsing / compilation.
      
      BUG=v8:5215
      R=bmeurer@chromium.org,neis@chromium.org,marja@chromium.org
      
      Review-Url: https://codereview.chromium.org/2302013002
      Cr-Commit-Position: refs/heads/master@{#39164}
      9b6ff3a8
  6. 01 Sep, 2016 1 commit
  7. 29 Aug, 2016 1 commit
  8. 08 Aug, 2016 1 commit
  9. 02 Aug, 2016 2 commits
  10. 01 Aug, 2016 1 commit
  11. 25 Jul, 2016 1 commit
  12. 13 Jul, 2016 1 commit
  13. 28 Jun, 2016 2 commits
  14. 21 Jun, 2016 1 commit
  15. 20 Jun, 2016 1 commit
    • adamk's avatar
      [cleanup] Remove dead code from DeclareLookupSlot and rename it · cbc6adc8
      adamk authored
      Runtime_DeclareLookupSlot is used when generating code for var and function declarations
      originating in an eval. Over time, it's accumulated quite a bit of cruft, which this CL removes:
      
        - With legacy const gone, lookup slots never have any property attributes.
        - There was a bit signaling that the variable was from an eval, but that was redundant since
          DeclareLookupSlot is only used for eval.
        - Some Proxy-related code didn't make sense here.
      
      Its name was also not terribly clear: while "LookupSlot" is used in several places, this
      particular function is only used for declaring variables and functions inside sloppy eval.
      Renamed (and split into two) to make this clear for future archeologists.
      
      Also added various DCHECKs to check the assumptions being made.
      
      Review-Url: https://codereview.chromium.org/2061173002
      Cr-Commit-Position: refs/heads/master@{#37111}
      cbc6adc8
  16. 13 Jun, 2016 2 commits
    • littledan's avatar
      Revert of change most cases of variable redeclaration from TypeError to... · 85c2c8d8
      littledan authored
      Revert of change most cases of variable redeclaration from TypeError to SyntaxError (patchset #8 id:140001 of https://codereview.chromium.org/2048703002/ )
      
      Reason for revert:
      This is going to break the LayoutTest inspector-protocol/console/console-let-const-with-api.html as seen in https://build.chromium.org/p/tryserver.v8/builders/v8_linux_blink_rel/builds/2247 . Please run this test manually, using instructions at https://www.chromium.org/developers/testing/webkit-layout-tests , and fix on the Chrome side if needed before resubmitting this patch.
      
      Original issue's description:
      > change most cases of variable redeclaration from TypeError to SyntaxError.
      >
      > Code like `let a; eval("var a;");` should throw a SyntaxError, not a TypeError
      > (this caused a test262 failure.). However, the code `eval("function NaN() {}");`
      > should actually throw a TypeError. This patch changes most cases of
      > redeclaration errors from TypeError to SyntaxError. See the test
      > mjsunit/regress/redeclaration-error-types for a thorough analysis with spec
      > references.
      >
      > The relevant sections of the spec are ES#sec-globaldeclarationinstantiation and
      > ES#sec-evaldeclarationinstantiation
      >
      > BUG=v8:4955
      > LOG=y
      >
      > Committed: https://crrev.com/2b787561763d0f7e8dab698652715a742cf78291
      > Cr-Commit-Position: refs/heads/master@{#36940}
      
      TBR=adamk@chromium.org,jwolfe@igalia.com
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4955
      
      Review-Url: https://codereview.chromium.org/2064793002
      Cr-Commit-Position: refs/heads/master@{#36941}
      85c2c8d8
    • jwolfe's avatar
      change most cases of variable redeclaration from TypeError to SyntaxError. · 2b787561
      jwolfe authored
      Code like `let a; eval("var a;");` should throw a SyntaxError, not a TypeError
      (this caused a test262 failure.). However, the code `eval("function NaN() {}");`
      should actually throw a TypeError. This patch changes most cases of
      redeclaration errors from TypeError to SyntaxError. See the test
      mjsunit/regress/redeclaration-error-types for a thorough analysis with spec
      references.
      
      The relevant sections of the spec are ES#sec-globaldeclarationinstantiation and
      ES#sec-evaldeclarationinstantiation
      
      BUG=v8:4955
      LOG=y
      
      Review-Url: https://codereview.chromium.org/2048703002
      Cr-Commit-Position: refs/heads/master@{#36940}
      2b787561
  17. 09 Jun, 2016 2 commits
  18. 06 Jun, 2016 1 commit
  19. 24 May, 2016 1 commit
  20. 13 May, 2016 1 commit
    • verwaest's avatar
      [runtime] Make sure that LookupIterator::OWN always performs a HIDDEN lookup as well. · c9a83150
      verwaest authored
      Hidden prototypes are merely an implementation detail. Properties on an object + hidden prototype should look like properties on the object. Hence we should always perform a hidden prototype lookup. This CL removes the option to ignore hidden prototypes to avoid bugs that leak this implementation detail.
      
      Also, the only previously valid cases were either places were we knew we didn't have a hidden prototype; or because we knew we (in the optimizing compiler) would only handle properties from the non-hidden object.The first case is already handled by directly tagging whether a receiver has a hidden prototype. In the second case we can just filter out properties from hidden prototypes.
      
      Review-Url: https://codereview.chromium.org/1975763002
      Cr-Commit-Position: refs/heads/master@{#36235}
      c9a83150
  21. 11 May, 2016 1 commit
  22. 19 Apr, 2016 1 commit
    • adamk's avatar
      Remove all non-function-name uses of CONST_LEGACY · 59546149
      adamk authored
      Now that all 'const' declarations are of the ES2015 variety, the only
      use of CONST_LEGACY is for function name bindings in sloppy mode
      named function expressions.
      
      This patch aims to delete all code meant to handle other cases, which
      mostly had to do with hole initialization/hole checks. Since function
      name bindings are initialized at entry to a function, it's impossible
      to ever observe one in an uninitialized state.
      
      To simplify the patch further, it removes the `IMPORT` VariableMode,
      as it's not likely to be needed (IMPORT is identical to CONST for
      the purpose of VariableMode).
      
      Review URL: https://codereview.chromium.org/1895973002
      
      Cr-Commit-Position: refs/heads/master@{#35632}
      59546149
  23. 17 Mar, 2016 1 commit
  24. 07 Mar, 2016 1 commit
  25. 01 Mar, 2016 1 commit
  26. 12 Feb, 2016 2 commits
    • bmeurer's avatar
      [runtime] Kill %Arguments and %ArgumentsLength. · 98aec4a7
      bmeurer authored
      This removes support for the %Arguments and %ArgumentsLength runtime
      entries and their intrinsic counterparts. If you need variable arguments
      in any builtin, either use (strict) arguments object or rest parameters,
      which are both compositional across inlining (in TurboFan), and not that
      much slower compared to the %_Arguments hackery.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1688163004
      
      Cr-Commit-Position: refs/heads/master@{#33943}
      98aec4a7
    • bmeurer's avatar
      [runtime] Introduce FastNewStrictArgumentsStub to optimize strict arguments. · 09d84535
      bmeurer authored
      The FastNewStrictArgumentsStub is very similar to the recently added
      FastNewRestParameterStub, it's actually almost a copy of it, except that
      it doesn't have the fast case we have for the empty rest parameter. This
      patch improves strict arguments in TurboFan and fullcodegen by up to 10x
      compared to the previous version.
      
      Also introduce proper JSSloppyArgumentsObject and JSStrictArgumentsObject
      for the in-object properties instead of having them as constants in the
      Heap class.
      
      Drive-by-fix: Use this stub and the FastNewRestParameterStub in the
      interpreter to avoid the runtime call overhead for strict arguments
      and rest parameter creation.
      
      R=jarin@chromium.org
      TBR=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1693513002
      
      Cr-Commit-Position: refs/heads/master@{#33925}
      09d84535
  27. 11 Feb, 2016 1 commit
    • bmeurer's avatar
      [compiler] Sanitize entry points to LookupSlot access. · 4ff159bd
      bmeurer authored
      Add dedicated %LoadLookupSlot, %LoadLookupSlotInsideTypeof,
      %LoadLookupSlotForCall, %StoreLookupSlot_Sloppy and
      %StoreLookupSlot_Strict runtime entry points and use them
      appropriately in the various compilers. This way we can
      finally drop the machine operators from the JS graph level
      completely in TurboFan.
      
      Also drop the funky JSLoadDynamic operator from TurboFan,
      which was by now just a small wrapper around the runtime
      call to %LoadLookupSlot.
      
      R=mstarzinger@chromium.org
      
      Review URL: https://codereview.chromium.org/1683103002
      
      Cr-Commit-Position: refs/heads/master@{#33880}
      4ff159bd
  28. 08 Feb, 2016 1 commit
    • bmeurer's avatar
      [runtime] Optimize and unify rest parameters. · 3ef573e9
      bmeurer authored
      Replace the somewhat awkward RestParamAccessStub, which would always
      call into the runtime anyway with a proper FastNewRestParameterStub,
      which is basically based on the code that was already there for strict
      arguments object materialization. But for rest parameters we could
      optimize even further (leading to 8-10x improvements for functions with
      rest parameters), by fixing the internal formal parameter count:
      
      Every SharedFunctionInfo has a formal_parameter_count field, which
      specifies the number of formal parameters, and is used to decide whether
      we need to create an arguments adaptor frame when calling a function
      (i.e. if there's a mismatch between the actual and expected parameters).
      Previously the formal_parameter_count included the rest parameter, which
      was sort of unfortunate, as that meant that calling a function with only
      the non-rest parameters still required an arguments adaptor (plus some
      other oddities). Now with this CL we fix, so that we do no longer
      include the rest parameter in that count. Thereby checking for rest
      parameters is very efficient, as we only need to check whether there is
      an arguments adaptor frame, and if not create an empty array, otherwise
      check whether the arguments adaptor frame has more parameters than
      specified by the formal_parameter_count.
      
      The FastNewRestParameterStub is written in a way that it can be directly
      used by Ignition as well, and with some tweaks to the TurboFan backends
      and the CodeStubAssembler, we should be able to rewrite it as
      TurboFanCodeStub in the near future.
      
      Drive-by-fix: Refactor and unify the CreateArgumentsType which was
      different in TurboFan and Ignition; now we have a single enum class
      which is used in both TurboFan and Ignition.
      
      R=jarin@chromium.org, rmcilroy@chromium.org
      TBR=rossberg@chromium.org
      BUG=v8:2159
      LOG=n
      
      Review URL: https://codereview.chromium.org/1676883002
      
      Cr-Commit-Position: refs/heads/master@{#33809}
      3ef573e9
  29. 05 Feb, 2016 1 commit
    • mvstanton's avatar
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of... · 3f36e658
      mvstanton authored
      Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ )
      
      Reason for revert:
      Must revert for now due to chromium api natives issues.
      
      Original issue's description:
      > Type Feedback Vector lives in the closure
      >
      > (RELAND: the problem before was a missing write barrier for adding the code
      > entry to the new closure. It's been addressed with a new macro instruction
      > and test. The only change to this CL is the addition of two calls to
      > __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
      >
      > We get less "pollution" of type feedback if we have one vector per native
      > context, rather than one for the whole system. This CL moves the vector
      > appropriately.
      >
      > We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      > vector actually lives in the first slot of the literals array (indeed there is
      > great commonality between those arrays, they can be thought of as the same
      > thing). So we make greater effort to ensure there is a valid literals array
      > after compilation.
      >
      > This meant, for performance reasons, that we needed to extend
      > FastNewClosureStub to support creating closures with literals. And ultimately,
      > it drove us to move the optimized code map lookup out of FastNewClosureStub
      > and into the compile lazy builtin.
      >
      > The heap change is trivial so I TBR Hannes for it...
      > Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
      > And Benedikt reviewed it as well.
      >
      > TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
      >
      > BUG=
      >
      > Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
      > Cr-Commit-Position: refs/heads/master@{#33741}
      
      TBR=bmeurer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=
      
      Review URL: https://codereview.chromium.org/1670813005
      
      Cr-Commit-Position: refs/heads/master@{#33766}
      3f36e658
  30. 04 Feb, 2016 2 commits
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · bb31db3a
      mvstanton authored
      (RELAND: the problem before was a missing write barrier for adding the code
      entry to the new closure. It's been addressed with a new macro instruction
      and test. The only change to this CL is the addition of two calls to
      __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
      
      We get less "pollution" of type feedback if we have one vector per native
      context, rather than one for the whole system. This CL moves the vector
      appropriately.
      
      We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
      vector actually lives in the first slot of the literals array (indeed there is
      great commonality between those arrays, they can be thought of as the same
      thing). So we make greater effort to ensure there is a valid literals array
      after compilation.
      
      This meant, for performance reasons, that we needed to extend
      FastNewClosureStub to support creating closures with literals. And ultimately,
      it drove us to move the optimized code map lookup out of FastNewClosureStub
      and into the compile lazy builtin.
      
      The heap change is trivial so I TBR Hannes for it...
      Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
      And Benedikt reviewed it as well.
      
      TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1668103002
      
      Cr-Commit-Position: refs/heads/master@{#33741}
      bb31db3a
    • verwaest's avatar
      Reland of [runtime] further dismantle AccessorInfoHandling, reducing it to the single API usecase. · b6a35312
      verwaest authored
      BUG=
      
      Review URL: https://codereview.chromium.org/1667083002
      
      Cr-Commit-Position: refs/heads/master@{#33737}
      b6a35312
  31. 03 Feb, 2016 2 commits