- 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}
-
- 10 Mar, 2020 3 commits
-
-
Leszek Swirski authored
Rather than having an optional script id during ParseInfo creation (which is either selected lazily on script creation, or eagerly if based on an existing Script), always eagerly get either the desired script id (either from the Script or Isolate::GetNextScriptId()). This has the side-effect that we will currently no longer need to get the script id on background threads, but I'm not reverting the thread-safety of Isolate::GetNextScriptId in case it's needed again in the future. Bug: v8:10314 Change-Id: I8f2dd962d3652b1a84a5d704a099e57a1679aba5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096616 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#66649}
-
Leszek Swirski authored
Previously, ParseInfo would create a script (with CreateScript) based on its flags, and then set its own flags based on that created script. This created a weird circular dependency for some of those flags, and sometimes we would have valid flags before script creation (main thread compile), while other times not (streaming compile). Now we set the ParseInfo flags manually and uniformly before script creation, and check that they match the created script after it has been created. Bug: v8:10314 Change-Id: Ife886c77727cd228c944a4f97369a3e6365d8219 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093433 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66648}
-
Leszek Swirski authored
Change wrapped argument set-up to be closer to where it's needed: setting up a top-level SFI, or initializing a ParseInfo from a top-level SFI. This is a generally cleaner use of the interface, avoids splitting the setting of the funciton syntax kind and wrapped arguments (including checking script.is_wrapped() in two places for the same behaviour), plus it avoids unnecessarily creating wrapped_argument handles for functions inside a wrapped script. As a drive-by, rename ParseInfo::SetFlagsFromScript to a clearer ParseInfo::SetFlagsForFunctionInScript, to differentiate between flags from a script for top-level vs. non-top-level. Bug: v8:10314 Change-Id: Ibdaad957558c13a1528dcc3da1ba8f262f357e48 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093509 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66643}
-
- 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 2 commits
-
-
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}
-
Leszek Swirski authored
Add the remaining missing templatizations to allow an initial wiring in of the off-thread factory into streaming compilation finalization. The off-thread finalization is behind a flag, disabled by default: --finalize-streaming-on-background When the flag is enabled, background tasks will perform perform the finalization during their background execution, and will release the parser and compilation jobs once they are no longer needed. The implementation is complete enough for performance testing, but not enough for launch. Notably, there is no support for: * Class boilerplates (the code is marked unreachable), * Exceptions during finalization, i.e. parse/compile warnings/errors, * Allocation sampling, * Logging, * Asm.js, * Parallel complication tasks * Forced source positions (for "NeedsDetailedOptimizedCodeLineInfo()") This patch also adds some tracing events for the various stages of the off-thread finalization (including the main-thread merge) for further performance improvements. Bug: chromium:1011762 Change-Id: Ia44fa56975dd689f0d92c1543b294cdb063eb199 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066965 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66566}
-
- 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}
-
- 24 Feb, 2020 1 commit
-
-
Shu-yu Guo authored
Currently implicit returns do not correctly resolve the async generator objects. This is observable via AsyncGenerator#throw as the implicit return won't override the rejection. Bug: v8:10238 Change-Id: I012fc3507d1e4106e7f35b21275be180a6e274c3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2065343Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#66413}
-
- 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}
-
- 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
-
-
Leszek Swirski authored
Adds support for off-thread allocation to Script allocation and line-end calculation. This includes adding support for keeping/merging a script list on the OffThreadIsolate, and adding syntactical support for logging (in the future this could do actual logging). Bug: chromium:1011762 Change-Id: Id90f2ad7458e90e06f6926f1fce7ef7a1ef50b3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2046884Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66213}
-
- 10 Feb, 2020 1 commit
-
-
Michael Achenbach authored
This makes creating whitelisted runtime functions more permissive on fuzzers (when --allow-natives-for-fuzzing is passed). - Runtime functions with too few arguments are replaced with undefined. - Superfluous arguments are ignored. This reduces syntax-error rate on fuzzers. Also prevents dcheck errors when fuzzing debug builds and fuzzers use too many arguments for runtime functions. Bug: chromium:1044942 Change-Id: I23b45398421c50bc82d1e8bfdf019f565253db96 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039352 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66202}
-
- 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}
-
- 04 Feb, 2020 2 commits
-
-
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}
-
Toon Verwaest authored
This changes how we setup modules from being entirely bytecode based to a single fixed array with metadata that's passed into a runtime function DeclareModuleExports, similar to DeclareGlobals. This is preperatory work to replace the bytecode that calls those functions with explicit calls before we even start running the code. In the case of modules that will obviate the need for modules to be generators. Change-Id: Ibf1c913a9dc78041e3001b174c66ab89226d9c8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030733 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66097}
-
- 31 Jan, 2020 1 commit
-
-
Michael Achenbach authored
This adds two flags for whitelisting natives on fuzzers: --allow-natives-for-fuzzing: Enables a small subset of runtime functions and replaces others with undefined. --allow-natives-for-differential-fuzzing Restricts the allowed runtime functions even further, excluding the ones that break differential fuzzing. Bug: chromium:1044942 Change-Id: I890bd4a6ff7c2e483dd74155290a7ace06f85239 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020773Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#66068}
-
- 30 Jan, 2020 1 commit
-
-
Jan Krems authored
When the file begins with a hashbang, the scanner is in a failed state when SkipHashbang() is called. This is usually not an issue but when the parser encounters an ILLEGAL token, it will reset the SyntaxError location because of it. Bug: v8:10110 Change-Id: I1c7344bf5ad20079cff80130c991f3bff4d7e9a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1995312Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66038}
-
- 28 Jan, 2020 1 commit
-
-
Simon Zünd authored
This CL fixes a parser crash in REPL mode. Some SyntaxErrors can cause the AST to contain NULL nodes, resulting in a crash when we want to rewrite the AST after parsing. Instead of re-writing a broken AST we bail early. R=leszeks@chromium.org Bug: chromium:1040034, chromium:1045758 Change-Id: I9c559f6de5969c8db17833ccbdb1608627b46311 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2023547Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#66008}
-
- 22 Jan, 2020 2 commits
-
-
Toon Verwaest authored
Changing script context handling from bytecode based to metadata on the function. This fixes the debugger to explicitly check the code rather than implicitly relying on a NewScriptContext bytecode causing side effects. Bug: chromium:1043151 Tbr: ulan@chromium.org Change-Id: I38c5c04d7c76155e0a055ae6efd57f25986bdb7d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013117Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65920}
-
Peter Marshall authored
Reason: Breaks side-effect free debug evaluate for let/const declarations Revert "[interpreter/runtime] Create ScriptContext before Script invocation" This reverts commit 9e51f79e. Revert "[interpreter/runtime] Hole script let/const requiring initialization in NewScriptContext" This reverts commit a128e38f. TBR=verwaest@chromium.org,leszeks@chromium.org,szuend@chromium.org,ulan@chromium.org Bug: chromium:1043151 Change-Id: Ib802789f45f8d7dbb4c2ccc30c6246e32155a92b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2013112 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#65915}
-
- 16 Jan, 2020 2 commits
-
-
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}
-
Toon Verwaest authored
This way we don't need to generate bytecodes to push the context. This drops the stack trace for redeclaration SyntaxErrors but keeps the message location. This is in line with what we do for other SyntaxErrors. Change-Id: Id8e3cc348b4d56a8196753baf51cfd810f07512b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997439 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#65810}
-
- 13 Jan, 2020 1 commit
-
-
legendecas authored
Fixed: v8:10083 Change-Id: I50e01022b1d1219ad8b31dd71f58f5bc9c9d10bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1987845 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65719}
-
- 08 Jan, 2020 1 commit
-
-
Leszek Swirski authored
Remove the explicit script handle from ParseInfo, and make it either a Handle that is passed around where needed, or one inferred from the SharedFunctionInfo. This will be useful for compilation finalization using the off-thread factory, which will not generate real Handles since it has no access to the Isolate. Bug: chromium:1011762 Change-Id: I5d9564009ec83bb9fc74191b4aa69735d132c2f7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977861Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#65629}
-
- 07 Jan, 2020 1 commit
-
-
Huáng Jùnliàng authored
When "await" is referenced in a part of an async arrow function head, we will walk up the active ambiguous expression stack and mark the ambiguous arrow head scope. However the class member initializer is always non-ambiguous so we should reset the stack and stop walking up. Bug: v8:10094 Change-Id: Iac35889158ef46c851888993b6081f8ff8610c43 Fixed: v8:10094 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1987620 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65600}
-
- 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}
-
- 19 Dec, 2019 1 commit
-
-
Shu-yu Guo authored
The spec was normatively changed to simplify var scopes for parameter expressions. Previously there was a per-parameter var scope in sloppy mode so direct evals could introduce vars that did not escape the parameter position. That semantics is complex both for the programmer and implementation and has resulted in bugs in the past. Furthermore, it has never been fully interoperable (with Safari in particular). The spec was instead changed to be simpler: to have a single var scope for sloppy evals in parameters that encloses the parameter scope and body scope. This simplification lets us remove expression-scope-reparenter. Drive-by removal of stale reference to PatternRewriter. Bug: v8:7532 Change-Id: Iade5594abe0009f7f3f6a1adad18628b17e1e779 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962471Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#65517}
-
- 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}
-
- 06 Dec, 2019 1 commit
-
-
Simon Zünd authored
This is a reland of 5bddc0e1 The original CL was speculatively reverted as it was suspected to cause failures on the non-determinism bot. This was ultimately confirmed to not be the case, so this CL is safe to reland as-is. Original change's description: > Implement top-level await for REPL mode > > Design doc: bit.ly/v8-repl-mode > > This CL allows the usage of 'await' without wrapping code in an async > function when using REPL mode in global evaluate. REPL mode evaluate > is changed to *always* return a Promise. The resolve value of the > promise is the completion value of the REPL script. > > The implementation is based on two existing mechanisms: > - Similar to async functions, the content of a REPL script is > enclosed in a synthetic 'try' block. Any thrown error > is used to reject the Promise of the REPL script. > > - The content of the synthetic 'try' block is also re-written the > same way a normal script is. This is, artificial assignments to > a ".result" variable are inserted to simulate a completion > value. The difference for REPL scripts is, that ".result" is > used to resolve the Promise of the REPL script. > > - ".result" is not returned directly but wrapped in an object > literal: "{ .repl_result: .result}". This is done to prevent > resolved promises from being chained and resolved prematurely: > > > Promse.resolve(42); > > should evaluate to a promise, not 42. > > Bug: chromium:1021921 > Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65273} TBR: yangguo@chromium.org,verwaest@chromium.org Bug: chromium:1021921 Change-Id: I95c5dc17593161009a533188f91b4cd67234c32f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1954388Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#65360}
-
- 04 Dec, 2019 1 commit
-
-
Maya Lekova authored
This reverts commit 5bddc0e1. Reason for revert: Possible culprit for https://bugs.chromium.org/p/chromium/issues/detail?id=1029863 Original change's description: > Implement top-level await for REPL mode > > Design doc: bit.ly/v8-repl-mode > > This CL allows the usage of 'await' without wrapping code in an async > function when using REPL mode in global evaluate. REPL mode evaluate > is changed to *always* return a Promise. The resolve value of the > promise is the completion value of the REPL script. > > The implementation is based on two existing mechanisms: > - Similar to async functions, the content of a REPL script is > enclosed in a synthetic 'try' block. Any thrown error > is used to reject the Promise of the REPL script. > > - The content of the synthetic 'try' block is also re-written the > same way a normal script is. This is, artificial assignments to > a ".result" variable are inserted to simulate a completion > value. The difference for REPL scripts is, that ".result" is > used to resolve the Promise of the REPL script. > > - ".result" is not returned directly but wrapped in an object > literal: "{ .repl_result: .result}". This is done to prevent > resolved promises from being chained and resolved prematurely: > > > Promse.resolve(42); > > should evaluate to a promise, not 42. > > Bug: chromium:1021921 > Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65273} TBR=yangguo@chromium.org,leszeks@chromium.org,verwaest@chromium.org,szuend@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:1021921 Change-Id: I9eaea584e2e09f3dffcbbca3d75a3c9bcb0a1adf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948719Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#65333}
-
- 02 Dec, 2019 1 commit
-
-
Simon Zünd authored
Design doc: bit.ly/v8-repl-mode This CL allows the usage of 'await' without wrapping code in an async function when using REPL mode in global evaluate. REPL mode evaluate is changed to *always* return a Promise. The resolve value of the promise is the completion value of the REPL script. The implementation is based on two existing mechanisms: - Similar to async functions, the content of a REPL script is enclosed in a synthetic 'try' block. Any thrown error is used to reject the Promise of the REPL script. - The content of the synthetic 'try' block is also re-written the same way a normal script is. This is, artificial assignments to a ".result" variable are inserted to simulate a completion value. The difference for REPL scripts is, that ".result" is used to resolve the Promise of the REPL script. - ".result" is not returned directly but wrapped in an object literal: "{ .repl_result: .result}". This is done to prevent resolved promises from being chained and resolved prematurely: > Promse.resolve(42); should evaluate to a promise, not 42. Bug: chromium:1021921 Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#65273}
-
- 26 Nov, 2019 1 commit
-
-
Toon Verwaest authored
Bug: chromium:1018611 Change-Id: I2d48673aa5a05e67a6b253415e66af975b693af5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1936470 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@{#65171}
-
- 25 Nov, 2019 1 commit
-
-
Dan Elphick authored
Converts and uses of RuntimeCallTimerScopes that switch the counter based on the thread, to use kThreadSpecific and remove the counter selection. Also moves RuntimeCallTimerScope::CounterMode to RuntimeCallStats, since now CorrectCurrentCounterId also takes it as a parameter. Bug: v8:10006 Change-Id: I14a503e0b83bb69c071f9665956de094bb33c0ba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1928864Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#65141}
-
- 15 Nov, 2019 1 commit
-
-
Dan Elphick authored
utils.h itself is fairly large and contains lots of unrelated functions as well as having a fair number of dependencies itself, so this splits bounds checking and bit field operations into their own headers in base and replaces uses of utils.h with the more appropriate header where possible. (Also fixes some cases where other headers were previously brought in transitively). Bug: v8:9810, v8:8912 Change-Id: I76c53f953848a57e2c5bfad6ce45abcd6d2a4f1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916604Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64983}
-
- 14 Nov, 2019 1 commit
-
-
Dan Elphick authored
Removes the include/v8.h from utils.h since it doesn't seem to need it. To make this work, add v8.h to a couple of files that really do need it. Bug: v8:9810 Change-Id: I9640a0df45cd7192f59d1fd8a722234f0d501a08 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916601Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64954}
-