- 19 Mar, 2020 2 commits
-
-
Leszek Swirski authored
This reverts commit d91679bf. Reason for revert: Seems to cause UBSan errors Original change's description: > [parser] Introduce UnoptimizedCompileFlags > > UnoptimizedCompileFlags defines the input flags shared between parse and > compile (currently parse-only). It is set initially with some values, and > is immutable after being passed to ParseInfo (ParseInfo still has getters > for the fields, but no setters). > > Since a few of the existing flags were output flags, ParseInfo now has a > new output_flags field, which will eventually migrate to a ParseOutputs > structure. > > Bug: v8:10314 > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66782} TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org Change-Id: Ica139e8862e00cd0560638a0236bbaccd7b2188c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10314 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108548Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66783}
-
Leszek Swirski authored
UnoptimizedCompileFlags defines the input flags shared between parse and compile (currently parse-only). It is set initially with some values, and is immutable after being passed to ParseInfo (ParseInfo still has getters for the fields, but no setters). Since a few of the existing flags were output flags, ParseInfo now has a new output_flags field, which will eventually migrate to a ParseOutputs structure. Bug: v8:10314 Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#66782}
-
- 18 Mar, 2020 1 commit
-
-
Leszek Swirski authored
Remove the wrapped arguments and outer scope info handles from ParseInfo, and instead infer them from the SharedFunctionInfo or Script, or in the case of eval pass it through to the parser as an argument. Bug: v8:10314 Change-Id: Ia1d1dbab5b62252e10fa2055f7e91f914324efd4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106200 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#66771}
-
- 12 Mar, 2020 1 commit
-
-
Leszek Swirski authored
Some Scope methods were unnecessarily taking a ParseInfo, or using only a single field from it. We can avoid passing around ParseInfo in these cases, which will make splitting/removing it easier in the future. Bug: v8:10314 Change-Id: I5c60783d27581c4f7d8c709314bbfc72ac5bd0f6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096630 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#66678}
-
- 09 Mar, 2020 1 commit
-
-
Joyee Cheung authored
When looking for private members in an object for the inspector, we check if that object is a class constructor with the a bit has_static_private_methods set on its SFI. If it is, we look for any variables in the context locals with a VariableMode associated with private methods or accessors and a IsStaticFlag being kStatic. This patch also filters out static private methods when inspecting instances. Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit See also: https://docs.google.com/document/d/14maU596YbHcWR7XR-_iXM_ANhAAmiuRlJZysM61lqaE/edit Bug: v8:9839, v8:8330 Change-Id: Idad15349c983898de2ce632c38b0174da10e639d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955664Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#66636}
-
- 03 Mar, 2020 1 commit
-
-
Joyee Cheung authored
When an empty class is nested inside a class with private instance methods, like this: class Outer { constructor() {} #method() {} factory() { class Inner { constructor() { } } return Inner; } run(obj) { obj.#method(); } } The bytecode generator previously generate private brand initialization for the constructor of Inner by mistake, because during scope chain serialization/deserialization, the outer scopes of Inner and factory() are not allocated or serialized (as they are empty). In the eyes of the bytecode generator, it then appeared as if Outer is the direct outer scope of Inner's constructor. In order to work around this information loss, in this patch we rely on SharedFunctionInfo instead of the Context/ScopeInfo chain to maintain the information about private brand initialization. This is done by shrinking expected_nof_properties to 8 bits and freeing 8 bits for a second bitfield on the SFI. Design doc: https://docs.google.com/document/d/14maU596YbHcWR7XR-_iXM_ANhAAmiuRlJZysM61lqaE/edit# Bug: v8:9839, v8:8330, v8:10098 Change-Id: I4370a0459bfc0da388052ad5a91aac59582d811d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2056889 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66575}
-
- 02 Mar, 2020 1 commit
-
-
Leszek Swirski authored
Remove OffThreadHandle, HandleOrOffThreadHandle, and HandleFor, and make the OffThreadIsolate allocate "real" Handles. Rather than using the main-thread Isolate's handle scopes, these off-thread Handles are backed by a Zone, which is tied to the lifetime of the nearest OffThreadHandleScope. Eventually, we'll likely want to merge the implementation of OffThreadHandleScope and HandleScope, but currently the latter is too tightly coupled to the main thread to do so. Bug: chromium:1011762 Change-Id: I2a6361931fe3f90a7bef4cc28ee42155fa8d062f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071865Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66516}
-
- 20 Feb, 2020 1 commit
-
-
Toon Verwaest authored
Change-Id: I1499b15c18fde43193a5e6312b71b29892dad70b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049849 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66369}
-
- 18 Feb, 2020 1 commit
-
-
Toon Verwaest authored
Bug: v8:8088 Change-Id: Ie92499a43e2286e9bb1c64b0d553a515d74d5aa2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2059989Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66313}
-
- 17 Feb, 2020 1 commit
-
-
Jakob Kummerow authored
By replacing usage of the IsNotArrayIndex bit with IsNotIntegerIndex, we get back one bit that we can use to increase the number of hash bits stored. The price is that strings that represent array/integer indices beyond the cacheable range will have to be scanned more often, but these strings should be rare, and we expect that the additional hash bit is more worthwhile to have. Bug: v8:9904 Change-Id: I33f74b0a73f4754aee85805d4b7c409177668439 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051947Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66299}
-
- 13 Feb, 2020 1 commit
-
-
Leszek Swirski authored
This is a reland of 453e1a3b Added canonical "empty" arrays to ScannerStream::ForTesting, for the zero-length nullptr data case. Original change's description: > [offthread] Add SFI support to OffThreadFactory > > Add support for off-thread SharedFunctionInfo allocation, which > includes UncompiledData and PreparseData allocation. > > Bug: chromium:1011762 > Change-Id: Ia10f9ce762c7d7eb1108b9e71da75131dce919b7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050393 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66246} TBR=ulan@chromium.org Bug: chromium:1011762 Change-Id: I37d2c6b9317548922913887940a0164cc2067efb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054085Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66253}
-
- 12 Feb, 2020 2 commits
-
-
Maya Lekova authored
This reverts commit 453e1a3b. Reason for revert: Makes UBSan unhappy - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/9893 Original change's description: > [offthread] Add SFI support to OffThreadFactory > > Add support for off-thread SharedFunctionInfo allocation, which > includes UncompiledData and PreparseData allocation. > > Bug: chromium:1011762 > Change-Id: Ia10f9ce762c7d7eb1108b9e71da75131dce919b7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050393 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66246} TBR=ulan@chromium.org,leszeks@chromium.org,ishell@chromium.org Change-Id: I26bc40ec1c351613f19745aed83f0c3a9fdd9a20 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:1011762 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2052172Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#66247}
-
Leszek Swirski authored
Add support for off-thread SharedFunctionInfo allocation, which includes UncompiledData and PreparseData allocation. Bug: chromium:1011762 Change-Id: Ia10f9ce762c7d7eb1108b9e71da75131dce919b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2050393 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#66246}
-
- 11 Feb, 2020 1 commit
-
-
Toon Verwaest authored
Change-Id: Iebdf095600186988abd7b1f13a1a2d9f566e5d7c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049845 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@{#66216}
-
- 10 Feb, 2020 2 commits
-
-
Leszek Swirski authored
Take advantage of the HandleOrOffThreadHandle implicit conversions where applicable. Bug: chromium:1011762 Change-Id: Iaf49d9098368b402e1cd3d991629d3f5e718f28e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2046885 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#66199}
-
Leszek Swirski authored
Make Scope allocation and ScopeInfo creation Isolate-templated. This includes making SourceTextModuleInfo allocation templated -- modules aren't currently streamed off-thread, but will hopefully be in the future, so this future-proofs them against that. Bug: chromium:1011762 Change-Id: I8954e08e8e81489eb821b5f62ec35a5be31fce09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043790Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66197}
-
- 07 Feb, 2020 1 commit
-
-
Leszek Swirski authored
Allow caching the result of allocating AstConsStrings, to allow sharing of inferred names between functions. This is a partial revert of https://crrev.com/c/2020953, with the observation that *some* AstConsStrings are always flattened, while others are only ever used as ConsStrings, so we want to allow the allocation to be lazy while still caching the result. As a drive-by, cleanup the old AstConsString linked list fields. Bug: chromium:1011762 Bug: chromium:1048082 Change-Id: Icc14342eb3f6f97359596b42b2c296cbc49fd791 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042093 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66168}
-
- 06 Feb, 2020 1 commit
-
-
Leszek Swirski authored
Add off-thread support for literals, including object/array boilerplates. Notably, this includes adding FixedArray and HeapNumber support to OffThreadFactory. As a drive-by, OffThreadHandle is redefined to store an Address rather than an Object, similar to Handle, so that it still works with forward definitions of types. Bug: chromium:1011762 Change-Id: I7c8452f450d8c57fe683a9e44532ce5647c84a11 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036084 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#66156}
-
- 05 Feb, 2020 1 commit
-
-
Sathya Gunasekaran authored
The source position is set to the function call (console.log) not the spread (..x), in the bytecode generator, as the spread operation is done as part of the CallWithSpread bytecode. The CallPrinter stops at the function call and doesn't look at the arguments as well (in CallPrinter::VisitCall) to see if the error is from an incorrect spread operation. With this patch, we pass some state to the CallPrinter in the CallWithSpread error case and check that in CallPrinter::VisitCall before returning. For the given source string: ``` x = undefined; console.log(1, ...x); ``` Previously, the error was - ``` test.js:2: TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator)) console.log(1, ...x); ^ TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator)) at test.js:2:9 ``` Now, the error is - ``` _test.js:2: TypeError: x is not iterable (cannot read property undefined) console.log(1, ...x); ^ TypeError: x is not iterable (cannot read property undefined) at _test.js:2:9 ``` Bug: v8:10038 Change-Id: I199de9997f1d949c6f9b7b4f41d51f422b8b5131 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037431Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#66131}
-
- 04 Feb, 2020 1 commit
-
-
Leszek Swirski authored
The Factory/OffThreadFactory allows us to cleanly separate object construction behaviour between main-thread and off-thread in a syntactically consistent way (so that methods templated on the factory type can be made to work on both). However, there are cases where we also have to access the Isolate, for handle creation or exception throwing. So far we have been pushing more and more "customization points" into the factories to allow these factory-templated methods to dispatch on this isolate behaviour via these factory methods. Unfortunately, this is an increasing layering violation between Factory and Isolate, particularly around exception handling. Now, we introduce an OffThreadIsolate, analogous to Isolate in the same way as OffThreadFactory is analogous to Factory. All methods which were templated on Factory are now templated on Isolate, and methods which used to take an Isolate, and which were recently changed to take a templated Factory, are changed/reverted to take a templated Isolate. OffThreadFactory gets an isolate() method to match Factory's. Notably, FactoryHandle is changed to "HandleFor", where the template argument can be either of the Isolate type or the Factory type (allowing us to dispatch on both depending on what is available). Bug: chromium:1011762 Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66101}
-
- 30 Jan, 2020 1 commit
-
-
Leszek Swirski authored
Remove AstConsString "internalization", and instead make the conversion to heap String be on-demand with an Allocate method. We never actually need the heapified cons string more than once, so there's no need to do the internalization walk or do the next/string union dance in the AstConsString class. This also allows us to specify how we want to allocate the String at the call site. In particular, it allows us to allocate a flat SeqString rather rather than a ConsString. This allows us to avoid allocating ConsStrings which will just be passed to a flatten call, and especially avoid allocating dead ConsStrings in the off-thread old space. Bug: chromium:1011762 Bug: chromium:1043168 Change-Id: Id851f2f7529d92ad7e5388eb22823fd6d1959cd0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020953Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66042}
-
- 29 Jan, 2020 1 commit
-
-
Leszek Swirski authored
In the case of function names, we allocate ConsStrings only to flatten them during finalization. Allocating these ConsStrings in old space appears to have regressed some benchmarks (especially memory benchmarks), but is necessary for off-thread allocation which doesn't have a young space. Ideally, we would avoid allocating these ConsStrings in the first place, and would flatten the data directly from the AstConsString. For now, we make them allocate in old space for off-thread allocation only, to revert the regressions. In the future we can investigate smarter flattening. Bug: chromium:1011762 Bug: chromium:1044477, chromium:1044147, chromium:1043573, chromium:1043168 Change-Id: If24b738d6f2eeb8c0fea042a711deb2a19015fbd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020948 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66025}
-
- 27 Jan, 2020 1 commit
-
-
Leszek Swirski authored
Change-Id: I64b2ae64dc668a937be0bf2950199b4f3d543f50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020778 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66002}
-
- 17 Jan, 2020 1 commit
-
-
Bill Ticehurst authored
The change at https://chromium-review.googlesource.com/c/v8/v8/+/1993971 introduced some new exports, but it appears the wrong macro was used for the component being built (V8_BASE_EXPORT rather than V8_EXPORT_PRIVATE) This breaks DLL builds (at least on MSVC, which I just fixed via https://chromium-review.googlesource.com/c/v8/v8/+/1996157). Adding Leszek who made the change, and Ulan and Toon as area OWNERS. Bug: v8:8791 Change-Id: I916553992f7d42cba0f4d8ae46b014df6c5ef633 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2005528 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65833}
-
- 16 Jan, 2020 2 commits
-
-
Leszek Swirski authored
When buildin an array boilerplate description, we currently walk the array literal as if it had tagged pointers, and post-hoc copy it to a FixedDoubleArray if it had double elements kind. Now, we calculate the elements kind during the InitDepthAndFlags walk, and if the elements kind is Double, we allocate a FixedDoubleArray to start with, and convert the elements of the array literal directly to unboxed doubles in the array. Change-Id: I56561e0af2236e785498eb70cb37eddcb09a56ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002529 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65817}
-
Leszek Swirski authored
Add support for internalizing an AstValueFactory using the off-thread factory. Includes adding ConsString support to OffThreadFactory. This introduces a Handle union wrapper, which is used in locations that can store a Handle or an OffThreadHandle. This is used in this patch for the internalized "string" field of AST strings, and will be able to be used for other similar fields in other classes (e.g. the ScopeInfo handle in Scope, object boilerplate descriptor handles, the inferred name handle on FunctionLiterals, etc.). It has a Factory-templated getter which returns the appropriate handle for the factory, and a debug-only tag to make sure the right getter is used at runtime. This union wrapper currently decomposes implicitly to a Handle if the getter is not called, to minimise code changes, but this implicit conversion will likely be removed for clarity. Bug: chromium:1011762 Change-Id: I5dd3a7bbdc483b66f5ff687e0079c545b636dc13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993971 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65816}
-
- 14 Jan, 2020 2 commits
-
-
Leszek Swirski authored
The fix in https://crrev.com/c/1997135 didn't properly recurse the cache scope after a with scope, passing the current scope rather than the original cache scope up the recursion. Now the "use external cache" check is done in LookupWith (and, analogously, LookupSloppyEval) while passing the given cache scope through the Lookup recursion. Fixed: chromium:1041210 Fixed: chromium:1041616 Change-Id: I5ac9ddc6c16d63b59aa034721fccec2f7781c4f8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000133 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#65754}
-
Maya Lekova authored
This reverts commit 304e97d3. Reason for revert: Last roll is failing - https://ci.chromium.org/p/chromium/builders/try/linux-rel/282356 Original change's description: > [parser] Fix caching dynamic vars on wrong scope > > When looking up a variable in a deserialized WITH scope, we were > unconditionally passing in the cache scope to the lookup, even if the > with was inside the cache scope. This would lead to and outer scope of > the with holding the generated dynamic variable. If the cache scope was > the SCRIPT scope, the dynamic variable would be interpreted as a global > object property. > > Now, we only store the WITH scope dynamic variables in the cache scope > if it is an inner scope of the WITH scope, same as we do for 'normal' > scope lookups. > > Fixed: chromium:1041210 > Change-Id: I4e8eb25bbb8ea58311355d13a9c7c97bf2fa3ec7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997135 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65732} TBR=leszeks@chromium.org,verwaest@chromium.org Change-Id: I7b6d77d03b603152a9a47541db466934f46b1176 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2000140Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#65747}
-
- 13 Jan, 2020 1 commit
-
-
Leszek Swirski authored
When looking up a variable in a deserialized WITH scope, we were unconditionally passing in the cache scope to the lookup, even if the with was inside the cache scope. This would lead to and outer scope of the with holding the generated dynamic variable. If the cache scope was the SCRIPT scope, the dynamic variable would be interpreted as a global object property. Now, we only store the WITH scope dynamic variables in the cache scope if it is an inner scope of the WITH scope, same as we do for 'normal' scope lookups. Fixed: chromium:1041210 Change-Id: I4e8eb25bbb8ea58311355d13a9c7c97bf2fa3ec7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997135Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#65732}
-
- 09 Jan, 2020 1 commit
-
-
Dan Elphick authored
When parsing an arrowhead, it's possible for temporary variables to be created with a different index depending on whether the parsing is lazy or eager. This then results in bytecode mismatches as the index is used to determine which register to use. To make the ordering stable, this changes variable allocation in arrow functions to always allocate the non-temporaries first and then the temporaries. Bug: chromium:1020162 Change-Id: Ia47c4c2916d63f12d20d663e4e3842bfd68f6d8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977865 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65657}
-
- 08 Jan, 2020 2 commits
-
-
Leszek Swirski authored
This reverts commit 7a0ae73b. Reason for revert: Not useful after all, no tests, we can reland if we do end up needing it. Original change's description: > [ast] Add a Flatten method for AstConsString > > This allows off-thread flattening. > > Bug: chromium:1011762 > Change-Id: If83f7bbcbf74165987a4c157184f5b92dc554971 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924437 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65075} TBR=leszeks@chromium.org,verwaest@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:1011762 Change-Id: Ia72e5abdc9b6149a337565576806427dcd1d11c2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991484Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#65638}
-
Leszek Swirski authored
AllocateScopeInfos should only be called for not-yet unallocated scopes, so we can DCHECK for nullness rather than having a branch for it. Change-Id: I65767c22d6fd7b12c4564c5ecc52f9486229affa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981159Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#65623}
-
- 07 Jan, 2020 2 commits
-
-
Leszek Swirski authored
During conflict detection, we want to early exit the scope loop when we find a non-conflict, but continue looking at the other declarations in the scope. Bug: chromium:1038588 Change-Id: Ia2a19b02222fbd13cec70d3a60d2f5bae4ce245b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1985991 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65602}
-
Sigurd Schneider authored
This CL improves whitespace precision of coverage around try blocks; previously a small portion of whitespace could be reported as uncovered between try blocks and catch and/or finally blocks. Change-Id: I763ae3d15106c88f2278cf8893c12b0869a62528 Fixed: v8:10030 Bug: v8:10030 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962265Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#65593}
-
- 02 Jan, 2020 1 commit
-
-
Shu-yu Guo authored
The receiver may be undefined when calling optionally chained properties, so CallAnyReceiver should be used instead of CallProperty. TBR=rmcilroy@chromium.org Bug: chromium:1038178 Change-Id: Id91f2ecda1a5b38f6d1c9a6b6f90c0ae7dcbe638 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986205 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65580}
-
- 27 Dec, 2019 1 commit
-
-
Daniel Clifford authored
In the process: * Rework the Torque definition of ScopeInfo to enable direct field-style access of ScopeFlags, removing some dead code in the process. * Allow implicit FromConstexpr conversion from subtypes of 'constexpr A' to other types. This makes it possible/easy to convert constexpr versions of enums to other types, since the constexpr version of the enum isn't addressable. It's namespace isn't a valid namespace and is an implementation detail anyway. * Cleanup LanguageMode: Language mode is now an enum and directly mirrors the C++-side definition rather than being a Smi. With the changes above, a new type LanguageModeSmi is introduced that is the Smi representation of LanguageMode that can be implicitly casted from constexpr LanguageMode values. Change-Id: I190412f95e02905f445d149883fbf1f2b8ed757b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977159 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65561}
-
- 18 Dec, 2019 1 commit
-
-
Simon Zünd authored
When V8 throws an uncaught exception, we store a JSMessageObject with a stack trace and source positions on the isolate itself. The JSMessageObject can be retrieved by a TryCatch scope and is used by the inspector to provide additional information to the DevTools frontend (besides the exception). Introducing top-level await for REPL mode causes all thrown exceptions to be turned into a rejected promise. The implicit catch block that does this conversion clears the JSMessageObject from the isolate as to not leak memory. This CL preserves the JSMessageObject when the debugger is active and stores the JSMessageObject on the rejected promise itself. The inspector is changed to retrieve the JSMessageObject in the existing catch handler and pass the information along to the frontend. Drive-by: This CL removes a inspector test that made assumptions when a promise is cleaned up by the GC. These assumptions no longer hold since we hold on to the promise longer. Bug: chromium:1021921 Change-Id: Id0380e2cf3bd79aca05191bc4f3c616f6ced8db7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967375 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#65497}
-
- 13 Dec, 2019 1 commit
-
-
Michael Starzinger authored
R=hpayer@chromium.org Change-Id: I2b9a77317cd4dcf8502c237b7f8f167b80859859 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962866Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#65443}
-
- 10 Dec, 2019 1 commit
-
-
Simon Zünd authored
Bug: v8:10021 Change-Id: Ieffa39c09e028b9c0f91f1823ea6e89f81fec4cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948707 Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Simon Zünd <szuend@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65394}
-
- 09 Dec, 2019 1 commit
-
-
Leszek Swirski authored
We use the compilation entry point as a caching scope for deserializing lookups, to avoid redundantly iterating over parent scopes when accessing the same variable multiple times. However, this caching scope messes with lookups that are looking for lexical name conflicts, as opposed to just resolving variables. In particular, it messes with name conflict lookups and sloppy block function hoisting checks, when there are other scopes in the way, e.g. function f() { let x; try { throw 0; } catch (x) { // This catch is the entry scope // Naive use of caches will find the catch-bound x (which is // a VAR), and declare 'no conflict'. eval("var x;"); // Naive use of caches will find the catch-bound x (which is // a VAR), and determine that this function can be hoisted. eval("{ function x() {} }"); } } Previously, we worked around this by avoiding cache uses for these lookups, but this had the issue of instead caching the same variable multiple times, on different scopes. In particular, we saw: function f() { with ({}) { // This with is the entry scope, any other scope would do // though. // The conflict check on `var f` caches the function name // variable on the function scope, the subsequent 'real' // lookup of `f` caches the function name variable on the // entry i.e. with scope. eval("var f; f;"); } } With this patch, we change the caching behaviour to cache on the first non-eval declaration scope above the eval -- in the above examples, this becomes the parent function "f". For compilations with no intermediate non-decl scopes (no with or catch scopes between the function and eval) this becomes equivalent to the existing entry-point-based caching. This means that normal lookups do have to (sometimes) iterate more scopes, and we do have to be careful when using the cache to not use it for lookups in these intermediate scopes (a new IsOuterScope DCHECK guards against this), but we can now safely ignore the cache scope when doing the name-collision lookups, as they only iterate up to the outer non-eval declaration scope anyway. Bug: chromium:1026603 Bug: chromium:1029461 Change-Id: I9e7a96ce4b8adbc7ed47a49fba6fba58b526235b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955731 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65391}
-