- 22 Oct, 2019 1 commit
-
-
Toon Verwaest authored
Parenthesized variable names are valid references for assignment. To make sure we can properly mark the variable as assigned, we should push parenthesized variables to the outer expression scope after the parenthesized expression is guaranteed to not be an arrow head; so that the variable list of the parent is complete. Technically we could probably get by with simply pushing a single variable, since more complex expressions aren't valid parenthesized assignment targets: (a) = ... and [(a),(b)] = ... are valid, but ([a,b]) = ... isn't. It doesn't really seem worth it though. Bug: chromium:1015372 Change-Id: I095c35126742a14d0171537b9795f7258c33ab4d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872389 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64455}
-
- 21 Oct, 2019 1 commit
-
-
Joshua Litt authored
Bug: chromium:1014458 Change-Id: I9e5e83da4452e9953218335353047f41c18f68fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864333 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#64428}
-
- 18 Oct, 2019 1 commit
-
-
Toon Verwaest authored
At certain points in time we learn that we have to drop certain errors in the ExpressionScope. If an AccumulationScope appears between where we learn about the error and where we drop the error, we previously stopped accumulating, assuming that we're already going to fail anyway. Since we might drop the earlier error later; we can't early on this. Instead the accumulator should simply keep on accumulating, keeping the earlier error alive across accumulation. Bug: chromium:1015567 Change-Id: I4d70643d02233fe82582b568a0a946eacf883880 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869198 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#64384}
-
- 10 Oct, 2019 2 commits
-
-
Joyee Cheung authored
This patch implements https://github.com/tc39/proposal-class-fields/pull/269 and makes sure we always throw TypeError when there is invalid private name access in computed property keys. Before this patch, private name variables of private fields and methods are initialized together with computed property keys in the order they are declared. Accessing undefined private names in the computed property keys thus fail silently. After this patch, we initialize the private name variables of private fields before we initialize the computed property keys, so that invalid access to private fields in the computed keys can be checked in the IC. We now also initialize the brand early, so that invalid access to private methods or accessors in the computed keys throw TypeError during brand checks - and since these accesses are guarded by brand checks, we can create the private methods and accessors after the class is defined, and merge the home object setting with the creation of the closures. Bug: v8:8330, v8:9611 Change-Id: I01363f7befac6cf9dd28ec229b99a99102bcf012 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846571 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64225}
-
Joyee Cheung authored
This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219}
-
- 09 Oct, 2019 1 commit
-
-
Joshua Litt authored
Trivial changes to the parser to allow parsing for-await. Unfortunately, these tests uncovered a stress bug related to using await in for loops(see v8:9825). Bug: v8:9817, v8:9825 Change-Id: Ie699c85389e94b834a22dc1fb2f9970fc37fcdd3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1848434Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#64193}
-
- 07 Oct, 2019 1 commit
-
-
Dan Elphick authored
Fixes spurious DCHECK triggering due to bug introduced in https://chromium-review.googlesource.com/c/v8/v8/+/1836258. Bug: chromium:1011596 Change-Id: Ia3b1eb25d326e465b3239f191aad11d90a2e56a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1844777Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64125}
-
- 04 Oct, 2019 1 commit
-
-
Dan Elphick authored
This deletes unresolved VariableProxy objects created for labels in the preparser which prevents shadowed variables in enclosing scopes from being context-allocated. Previously this was only done in the full parser, which leads to bytecode mismatches with lazy source positions. Bug: chromium:1009728, v8:8510 Change-Id: If2d0c345346116a7f5aacbcd0cf3638e9f7e04cc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1836258Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64104}
-
- 24 Sep, 2019 2 commits
-
-
Dan Elphick authored
Always unmark arrowhead parameters as assigned directly after their initialization as the parser doesn't know when it first sees the "assignment" that it may be in an arrowhead. Bug: chromium:1003403, v8:8510 Change-Id: Iad5a4136d5ec06331fc43b81a809fd72cee2dd65 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1815131 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63947}
-
Joshua Litt authored
Adds support for parsing top level await to V8, as well as many tests. This is the final cl in the series to add support for top level await to v8. Spec is here: https://tc39.es/proposal-top-level-await/#sec-execute-async-module Bug: v8:9344 Change-Id: Ie8f17ad8c7c60d1f6996d134ae154416cc1f31e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1703878Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#63946}
-
- 23 Sep, 2019 1 commit
-
-
Dan Elphick authored
Change Parser::AllowsLazyParsingWithoutUnresolvedVariables to return false if it may be parsing an arrow function. Bug: v8:9758, v8:8510 Change-Id: Ic5d213d4358ff954a169c03e449197c3f050880c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1816510Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#63920}
-
- 20 Sep, 2019 1 commit
-
-
Joshua Litt authored
doc: https://docs.google.com/document/d/1Y9uF3hS2aUrwKU56vGxlvEs_IiGgmWSzau8097Y-XBM/edit Bug: v8:7427 Change-Id: Iedd36c146cefff7e6687fdad48d263889c5c8347 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1778902 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63913}
-
- 18 Sep, 2019 1 commit
-
-
Clemens Hammacher authored
This is an unmodified reland of 9febc505. Nosnap bots do not block LKGR any more: https://crbug.com/v8/9737#c10. Original change's description: > Reland "Remove all custom CopyCharsUnsigned implementations" > > This is a reland of 5d8c4890 > > Original change's description: > > Remove all custom CopyCharsUnsigned implementations > > > > It's unclear whether the custom implementation have any advantage over > > the standard library one's. > > Since we update our toolchain and standard library regularly, it might > > well be the case that the custom implementations are slower by now. > > > > Thus this CL removes all {CopyCharsUnsigned} implementations and > > implements {CopyChars} generically using {std::copy_n}. > > > > Note that this does not touch the {MemMove} and {MemCopy} functions > > yet, as we have seen regressions when trying to remove them before > > (https://crbug.com/v8/8675#c5). > > > > R=leszeks@chromium.org > > > > Bug: v8:9396 > > Change-Id: I97a183afebcccd2fbb567bdba02e827331475608 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800577 > > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#63808} > > Bug: v8:9396 > Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng > Change-Id: I9cd754ebe6b802bb4aabd6d2a448de41da040874 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807357 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63823} TBR=leszeks@chromium.org Bug: v8:9396 Change-Id: I793524d76b8b9c93d2a98c73e8d72967880fe1cf Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809362 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63857}
-
- 17 Sep, 2019 2 commits
-
-
Adam Klein authored
This reverts commits 9febc505 (along with followup commit 60624b56). Reason for revert: Breaks win32 nosnap shared, blocking lkgr & roll: https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20nosnap%20-%20shared/35145 nosnap bots may be deprecated, but as long as they're in LKGR we need to mind them. Original change's description: > Reland "Remove all custom CopyCharsUnsigned implementations" > > This is a reland of 5d8c4890 > > Original change's description: > > Remove all custom CopyCharsUnsigned implementations > > > > It's unclear whether the custom implementation have any advantage over > > the standard library one's. > > Since we update our toolchain and standard library regularly, it might > > well be the case that the custom implementations are slower by now. > > > > Thus this CL removes all {CopyCharsUnsigned} implementations and > > implements {CopyChars} generically using {std::copy_n}. > > > > Note that this does not touch the {MemMove} and {MemCopy} functions > > yet, as we have seen regressions when trying to remove them before > > (https://crbug.com/v8/8675#c5). > > > > R=leszeks@chromium.org > > > > Bug: v8:9396 > > Change-Id: I97a183afebcccd2fbb567bdba02e827331475608 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800577 > > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#63808} > > Bug: v8:9396 > Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng > Change-Id: I9cd754ebe6b802bb4aabd6d2a448de41da040874 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807357 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63823} TBR=leszeks@chromium.org,clemensh@chromium.org Change-Id: Ic53ab2293d5dc7722a1121d1aa1159328a6ed8f5 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9396 Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1808035Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#63854}
-
Clemens Hammacher authored
This is a reland of 5d8c4890 Original change's description: > Remove all custom CopyCharsUnsigned implementations > > It's unclear whether the custom implementation have any advantage over > the standard library one's. > Since we update our toolchain and standard library regularly, it might > well be the case that the custom implementations are slower by now. > > Thus this CL removes all {CopyCharsUnsigned} implementations and > implements {CopyChars} generically using {std::copy_n}. > > Note that this does not touch the {MemMove} and {MemCopy} functions > yet, as we have seen regressions when trying to remove them before > (https://crbug.com/v8/8675#c5). > > R=leszeks@chromium.org > > Bug: v8:9396 > Change-Id: I97a183afebcccd2fbb567bdba02e827331475608 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800577 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63808} Bug: v8:9396 Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng Change-Id: I9cd754ebe6b802bb4aabd6d2a448de41da040874 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807357Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63823}
-
- 16 Sep, 2019 3 commits
-
-
Adam Klein authored
This reverts commit 5d8c4890. Reason for revert: Fails on UBSan bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/7946 Original change's description: > Remove all custom CopyCharsUnsigned implementations > > It's unclear whether the custom implementation have any advantage over > the standard library one's. > Since we update our toolchain and standard library regularly, it might > well be the case that the custom implementations are slower by now. > > Thus this CL removes all {CopyCharsUnsigned} implementations and > implements {CopyChars} generically using {std::copy_n}. > > Note that this does not touch the {MemMove} and {MemCopy} functions > yet, as we have seen regressions when trying to remove them before > (https://crbug.com/v8/8675#c5). > > R=leszeks@chromium.org > > Bug: v8:9396 > Change-Id: I97a183afebcccd2fbb567bdba02e827331475608 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800577 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63808} TBR=leszeks@chromium.org,clemensh@chromium.org Change-Id: Ia16da942c7c28ba71076d1e3b0b8a6388a4ba359 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9396 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1806103Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#63810}
-
Clemens Hammacher authored
It's unclear whether the custom implementation have any advantage over the standard library one's. Since we update our toolchain and standard library regularly, it might well be the case that the custom implementations are slower by now. Thus this CL removes all {CopyCharsUnsigned} implementations and implements {CopyChars} generically using {std::copy_n}. Note that this does not touch the {MemMove} and {MemCopy} functions yet, as we have seen regressions when trying to remove them before (https://crbug.com/v8/8675#c5). R=leszeks@chromium.org Bug: v8:9396 Change-Id: I97a183afebcccd2fbb567bdba02e827331475608 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800577 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63808}
-
Joshua Litt authored
Bug: v8:9647 Change-Id: Ib6449fadc42130a019788ba3a22e93bfd0de789b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803514 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63796}
-
- 13 Sep, 2019 1 commit
-
-
Clemens Hammacher authored
After https://crrev.com/c/1800575 and https://crrev.com/c/1803343, which tried to fix this on occuring compile errors, this CL systematically adds the <memory> include to each header that uses {std::unique_ptr}. R=sigurds@chromium.org TBR=mlippautz@chromium.org,alph@chromium.org,rmcilroy@chromium.org,verwaest@chromium.org Bug: v8:9396 Change-Id: If7f9c3140842f9543135dddd7344c0f357999da0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803349Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63767}
-
- 12 Sep, 2019 1 commit
-
-
Francis McCabe authored
Bug: v8:9429 Change-Id: I2b1bc81f72e7cc7657330bd778586f608d62809b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1797659Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#63724}
-
- 11 Sep, 2019 1 commit
-
-
Joyee Cheung authored
This patch uses a bit in the Variable bit fields to distinguish static private names from instance private names, so that we can check the conflicts of private accessors that are complementary but with different staticness in the parser, and use this information later when generating code for checking static brands for private method access. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: I8d70600e594e3d07f77ea519751b7ca2e0de87b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781010Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63677}
-
- 10 Sep, 2019 2 commits
-
-
Clemens Hammacher authored
Since we switched to C++14 now, we can use {std::make_unique} instead of our own {base::make_unique} from {template-utils.h}. R=mstarzinger@chromium.org, yangguo@chromium.org Bug: v8:9687 No-Try: true Change-Id: I660eb30038bbb079cee93c7861cd87ccd134f01b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789300 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63642}
-
Dan Elphick authored
When analyzing functions scopes with the script_scope as parent, don't skip migrating unresolved variables upwards if we could still be inside an arrow head, which means accesses to those variables will be correctly context allocated. Bug: v8:8510, chromium:1000094 Change-Id: I684f2f8bc692de420203990f93e5c943b5b769c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789705Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#63635}
-
- 06 Sep, 2019 1 commit
-
-
Shu-yu Guo authored
Expressions in class heritage position do not have access to the inheriting class's private names, only its lexical bindings. The parser currently uses the same scope chain for both. This CL makes scopes in class heritage position skip their outer class when resolving private names. Whether a scope needs to skip is kept as a bit on various scope-related data structures. See implementation doc at https://docs.google.com/document/d/1d3o_SQqcICxfjLMw53OOaiIQux0ppNHQJnjZHtCQLwA Bug: v8:9177 Change-Id: I77e491a9d4a261131274f12ddf052af7ac31a921 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1769486 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#63586}
-
- 05 Sep, 2019 1 commit
-
-
Sigurd Schneider authored
Async functions were not correctly fixed up for code coverage, which caused an additional uncovered range to be reported between a return statement and the closing bracket. This CL adds code that detects such ranges, and removes them, similarly to how the ranges are removed for normal functions. The removal process is different, because the parser rewrites async functions to contain a try-catch handling promise rejection. Change-Id: I73b08d64be74d26c32f2f9652d027430d4671251 Bug: chromium:981313, v8:8381 Change-Id: I82a7f0c54d3a48609ef5255a7659d9557e163566 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782837Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63561}
-
- 04 Sep, 2019 1 commit
-
-
Dan Elphick authored
Use the position of commas in async arrow expressions to mark the initializer position of any parameters that might have been set in the preceding parameter. This extends https://chromium-review.googlesource.com/c/v8/v8/+/1710671 to async arrow heads. Bug: v8:8510, chromium:997320 Change-Id: I98e0ac817c7f53fbf1dced98fb6891a386ee7803 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781057Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#63542}
-
- 03 Sep, 2019 1 commit
-
-
Toon Verwaest authored
Bug: chromium:999853 Change-Id: I5ff8a1d742b871487bc0b0235f4f24d0aaf5c20e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782176 Auto-Submit: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#63530}
-
- 29 Aug, 2019 1 commit
-
-
Leszek Swirski authored
Sloppy eval extends the outer declaration scope's context. This is also true for sloppy eval inside of other sloppy evals -- the outer declaration scope's context is extended rather than the outer sloppy eval's declaration scope. However, we consider eval scopes to also be declaration scopes, for the purposes of strict eval and caching lookup variables. So, we need to make sure that we skip through sloppy eval scopes when marking a scope as calls_sloppy_eval. In fact, we implement this rather as never marking sloppy eval scopes as calls_sloppy_eval, under the assumption that the parent scope will already have been marked calls_sloppy_eval by the outer eval. As a drive-by, fix a TODO to move this logic from calls_sloppy_eval() to RecordEvalCall(), rename the variable to something more meaningful, and make Snapshotting to use a new calls_eval bit on Scope. Bug: chromium:996751 Change-Id: I27ccc7ef429a7ce60b3bb02bf64a3820ae4a2c36 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773247 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63455}
-
- 27 Aug, 2019 2 commits
-
-
Joshua Litt authored
Launching nullish behind a flag resulted in a small performance regression in the adwords parsing benchmark. From local tests, doing a little manual PGO seemed to improve performance slightly. Parse.duration on this benchmark dropped from 1,639.188 ms to 1,535.312 ms Bug: chromium:997652 Change-Id: I537985793cdf310a0dda5a69ded9f0ea2c0a7fb0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773098 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63417}
-
Joyee Cheung authored
Previously variations of #constructor can be parsed when they are static. This patch throws early errors for them always. Bug: v8:8330 Change-Id: I51ab9b83f713c70d0896c0e8cab3282ef9a105f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1770332Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63413}
-
- 23 Aug, 2019 1 commit
-
-
Shu-yu Guo authored
- Rename FunctionLiteral::FunctionType to FunctionSyntaxKind. - Re-express IsWrappedBit, IsDeclarationBit, IsAnonymousExpressionBit, and IsNamedExpressionBit in SFI::flags as FunctionSyntaxKind. This frees up 1 bit in SFI::flags. - Re-express the analogous bits in ParseInfo as FunctionSyntaxKind. - Simplifies some logic in the back-and-forth passing of this info between SFI and ParseInfo. - Drive-by fix parsing class member initializations as kAccessorOrMethod. Bug: v8:9644 Change-Id: I6c165d5016d968f5057a32136385ddcdc4a46ef1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1767263Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#63388}
-
- 21 Aug, 2019 1 commit
-
-
Joshua Litt authored
This CL implements the nullish operator in bytecode as defined by: https://github.com/tc39/proposal-nullish-coalescing. It can be enabled by passing '--harmony-nullish'. Nullish is similar to logical operators, but instead of truthy/falsey values, it short circuits when it evaluates a null or undefined value. Bug: v8:9547 Change-Id: Ia0f55877fc2714482b5547942baef9733537d1b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738568Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#63317}
-
- 20 Aug, 2019 1 commit
-
-
Dan Elphick authored
Fixes bytecode mismatch between lazy and non-lazy where "this" was marked as maybe assigned in constructors that called the super constructor. Since this will return the hole in cases where it was not yet initialized by super (and the hole is explicitly handled by JSContextSpecialization::ReduceJSLoadContext), it's safe to treat it as a constant in all cases. In the case of lazy compilation case, "this" is never added to the ScopeInfo so is never seen as mutable. Bug: chromium:994719 Change-Id: I43478fbc626b19eb1533aa9dec61b7f276ae140b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762025 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63283}
-
- 13 Aug, 2019 1 commit
-
-
Ross McIlroy authored
When a RelocatingCharacterStream is Seeked, it's buffer_pos_ could be set a non-zero value. However, UpdateBufferPointers was assuming the position was zero to relocate the buffer_start_ and buffer_end_, which would lead to the stream becoming misaligned. Fix this and add a unittest and the clusterfuzz script which highlighted the issue. BUG=chromium:991133 Change-Id: I20dd510b3dcc5df6df058b7e06d2c8a838aef855 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751782Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63190}
-
- 12 Aug, 2019 2 commits
-
-
Ross McIlroy authored
This requires a native context which might not be available when collecting source positions, and errors are cleared in any case. BUG=chromium:992063 Change-Id: Ie0b81f60debaaf9a7810a42f56de0c005a7fbe18 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1745338 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63175}
-
Ross McIlroy authored
We have already parsed a function when we call CollectSourcePositions, so we shouldn't update the parsing statistics again otherwise we will double-count. Also, CollectSourcePositions needs to be made native-context independent, and Blink's CountUsage counter requires a context to have been entered when it is called and so isn't context independent. BUG=chromium:992063 Change-Id: Idda50b98a8308f022cb90e1a18afb43982e95298 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746472 Auto-Submit: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63151}
-
- 08 Aug, 2019 1 commit
-
-
Joshua Litt authored
Bug: v8:9603 Change-Id: I7a36c97feedaccf81509aae579f1594a0e7b1019 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743527Reviewed-by:
Mathias Bynens <mathias@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#63129}
-
- 07 Aug, 2019 1 commit
-
-
Gus Caplan authored
Each LHS expression that contains an optional chain of some form is wrapped in an OptionalChain node. This root node allows us to use a single jump location for every individual item in the chain, improving the performance and simplifying the implementation. Bug: v8:9553 Change-Id: I678563928b2dbfd6200bff55801919d4fd816962 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1723359 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63120}
-
- 05 Aug, 2019 1 commit
-
-
Clemens Hammacher authored
Instead of exposing a {kNext} constant to be used to construct the next bitfield, expose a templatized {Next} type alias. This ensures that the storage type is the same for all bitfields created this way. It's also shorter. Apart from the expected changes in the code base, the AST node classes are changed to expose a {NextBitField} templated type alias instead of a {kNextBitFieldIndex} constant. They thus follow the same pattern as {BitField} itself. R=jkummerow@chromium.org, mstarzinger@chromium.org, verwaest@chromium.org Bug: v8:9396 Change-Id: I70a1b0bd71cde694ec53444de0ca55e4cf0a3836 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728615Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63068}
-
- 01 Aug, 2019 1 commit
-
-
Joshua Litt authored
now that we are shipping this by default, we can remove the flag. Change-Id: I298691df3eec934a5add1aa2a2748a0f3a884ab6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726452 Commit-Queue: Joshua Litt <joshualitt@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#63026}
-