- 25 Feb, 2019 2 commits
-
-
Benedikt Meurer authored
When calling a known function from optimized code, where the number of actual arguments does not match the number of expected arguments, TurboFan has to call indirectly via the arguments adaptor trampoline, which creates an argument adaptor frame underneath the activation record for the callee. This is done so that the callee can still get to the actual arguments, using either 1. the arguments object, or 2. rest parameters (to get to superfluous arguments), or 3. the non-standard Function.arguments accessor (for sloppy mode functions), or 4. direct eval(), where we don't know whether there's a use of the arguments object hiding somewhere in the string. However going through the arguments adaptor trampoline is quite expensive usually, it seems to be responsible for over 60% of the call overhead in those cases. So this adds a fast path for the case of calling strict mode functions where we have an arguments mismatch, but where we are sure that the callee cannot observe the actual arguments. We use a bit on the SharedFunctionInfo to indicate that this is safe, which is controlled by hints from the Parser which knows whether the callee uses either arguments object or rest parameters. In those cases we use a direct call from optimized code, passing the expected arguments instead of the actual arguments. This improves the benchmark on the document below by around 60-65%, which is exactly the overhead of the arguments adaptor trampoline that we save in this case. This also adds a runtime flag --fast_calls_with_arguments_mismatches, which can be used to turn off the new behavior. This might be handy for checking the performance impact via Finch. Bug: v8:8895 Change-Id: Idea51dba7ee6cb989e86e0742eaf3516e5afe3c4 Cq-Include-Trybots: luci.chromium.try:linux-blink-rel Doc: http://bit.ly/v8-faster-calls-with-arguments-mismatch Reviewed-on: https://chromium-review.googlesource.com/c/1482735 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59825}
-
Sigurd Schneider authored
This removes ast.h as include from about ~500 includers of the latter. Bug: v8:8834 Change-Id: I294026d4bb29b878820d43c117b04a9645a457ae Reviewed-on: https://chromium-review.googlesource.com/c/1485835Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59822}
-
- 20 Feb, 2019 1 commit
-
-
Georg Neis authored
... as it can be expensive and there are no users of it anymore (we just read the information directly from ModuleInfo instead). Bug: v8:8847 Change-Id: I30a3bec186fbdea3821979e642b27b3b827309ce Reviewed-on: https://chromium-review.googlesource.com/c/1477220Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59718}
-
- 15 Feb, 2019 1 commit
-
-
Jakob Kummerow authored
This takes heap-inl.h out of the "Giant Include Cluster". Naturally, that means adding a bunch of explicit includes in a bunch of places that relied on transitively including them before. As of this patch, no header file outside src/heap/ includes heap-inl.h. Bug: v8:8562,v8:8499 Change-Id: I65fa763f90e66afc30d105b9277792721f05a6d4 Reviewed-on: https://chromium-review.googlesource.com/c/1459659 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59617}
-
- 14 Feb, 2019 1 commit
-
-
Dan Elphick authored
Class member initializer functions do not support lazy compilation, so change FunctionLiteral::AllowsLazyCompilation to return false for them. Change-Id: I38434f3a7e8c88af3f407cf19308fc3862ec4403 Reviewed-on: https://chromium-review.googlesource.com/c/1470103Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#59588}
-
- 13 Feb, 2019 1 commit
-
-
Toon Verwaest authored
We'll let the bytecode compiler and optimizing compilers deal with dead code, rather than the ast visitors. The problem is that the visitors previously disagreed upon what was dead. That's bad if necessary visitors omit parts of the code that the bytecode generator will actually visit. I did consider removing the AST nodes immediately in the parser, but that adds overhead and actually broke code coverage. Since dead code shouldn't be shipped to the browser anyway (and we can still omit it later in the bytecode generator), I opted for keeping the nodes instead. Change-Id: Ib02fa9031b17556d2e1d46af6648356486f8433d Reviewed-on: https://chromium-review.googlesource.com/c/1470108 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#59569}
-
- 06 Feb, 2019 2 commits
-
-
Toon Verwaest authored
Otherwise preparsed variables will cause unnecessary dynamic variable allocation, which is especially bad when we're preparsing top-level functions with references to other global variables. Change-Id: I2fa17dae8c1cc5264a26ddc8b8868de1d791b0ac Reviewed-on: https://chromium-review.googlesource.com/c/1456040 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#59420}
-
Toon Verwaest authored
"this" is a very common expression. By using a single ThisExpression object we can both avoid allocating many unnecessary VariableProxies and specialize the resolution of this since we know where it's declared up-front. This also avoids having to special-case "this" reference handling in the paths that would behave differently for "this" than for regular references; e.g., with-scopes. The tricky pieces are due to DebugEvaluate and this/super() used as default parameters of arrow functions. In the former case we replace the WITH_SCOPE with FUNCTION_SCOPE so that we make sure that "this" is intercepted, and still rely on regular dynamic variable lookup. Arrow functions are dealt with by marking "this" use in ArrowHeadParsingScopes. If the parenthesized expression ends up being an arrow function, we force context allocate on the outer scope (and mark "has_this_reference" on the FUNCTION_SCOPE so DebugEvaluate in the arrow function can expose "this"). The CL also removes the now unused ThisFunction AST node. Change-Id: I0ca38ab92ff58c2f731e07db2fbe91df901681ef Reviewed-on: https://chromium-review.googlesource.com/c/1448313Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59393}
-
- 31 Jan, 2019 1 commit
-
-
Camillo Bruni authored
Drive-by-fix: - Inline Scope::num_parameters - Provide inlineable DataGatheringScope destructor precheck Change-Id: I337a79e0d5cf0f26c526e2ac53de8aa632d86c53 Reviewed-on: https://chromium-review.googlesource.com/c/1445879 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59253}
-
- 28 Jan, 2019 4 commits
-
-
Leszek Swirski authored
Vars without initialisers don't need to allocate a VariableProxy, as the proxy expression is not really needed for anything. So, we can special case declaration parsing to look ahead for a '=' (plus a few other cases), and skip the variable proxy allocation if it isn't there. As a side-effect, variables that are only declared but never used are no longer marked is_used, and thus not allocated. This saves on generating dead code. Change-Id: Ie4f04c6b5c1138df4c2e17acf1f0150459b3b571 Reviewed-on: https://chromium-review.googlesource.com/c/1434376 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#59129}
-
Toon Verwaest authored
Change-Id: I8971d1e2ab47599bba4db8cac8631bcf39058593 Reviewed-on: https://chromium-review.googlesource.com/c/1436024Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59128}
-
Camillo Bruni authored
- Dehandlify ScopeInfo::ContextSlotIndex - Dehandlify ScriptContextTable::Lookup - Introduce function-kind.h with range-based helper methods - Spread usage of Scope::is_script_scope and friends Change-Id: I8ed1d82cc5bb9ea3fce856e16e9eafe194fb57ba Reviewed-on: https://chromium-review.googlesource.com/c/1430100Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#59120}
-
Camillo Bruni authored
Change-Id: Ia082e676e2cabab07c99b424f80b91e9459f1d3d Reviewed-on: https://chromium-review.googlesource.com/c/1430070Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#59112}
-
- 25 Jan, 2019 3 commits
-
-
Jakob Kummerow authored
Not even when copying 0 bytes. Same for memmove and memcmp. Bug: v8:3770 Change-Id: I3ed45a4572467ec7a9fc697ac28c004aa9b8b274 Reviewed-on: https://chromium-review.googlesource.com/c/1436217Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#59101}
-
Toon Verwaest authored
Change-Id: I83dc3bed644361be1b94063daefd890b10ba50cd Reviewed-on: https://chromium-review.googlesource.com/c/1433772 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#59095}
-
Leszek Swirski authored
Declare Variables with a name and position, rather than by passing through a VariableProxy. This allows us to not create dummy proxies for things like function declarations, and allows us to consider those declarations unused. As a side-effect, we also have to check if a variable is unused in the bytecode generator (as it will no longer be allocated), and we end up skip generating code/SFIs for dead variables/functions. Change-Id: I4c2c872473f23e124f9456b4b92f87159658f8e0 Reviewed-on: https://chromium-review.googlesource.com/c/1414916 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#59088}
-
- 24 Jan, 2019 1 commit
-
-
Toon Verwaest authored
This allows us to do fewer checks on the common path. Change-Id: I2d1a9239cbf7b637bdbc2a15abaadae225410acf Reviewed-on: https://chromium-review.googlesource.com/c/1430700Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59078}
-
- 23 Jan, 2019 2 commits
-
-
Toon Verwaest authored
Also insert NestedVariableDeclarations in the preparser if they occur. This should be uncommon enough to not hurt preparser performance. This will also allow us to stop checking for conflicts on already preparsed code. Since the preparser itself will mainly run off the main thread, this can allow us to free some main-thread time. Bug: v8:7829, v8:8706 Change-Id: I03f2690eb7b22e941995d6f2697e64211ddbeffb Reviewed-on: https://chromium-review.googlesource.com/c/1430069Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59044}
-
Camillo Bruni authored
- Inline single-call-site functions - Pull out pre-check from AllocateVariablesRecursively Change-Id: Ieceaf2d5b3ef6902b293d09e6fa63e58e60f3607 Reviewed-on: https://chromium-review.googlesource.com/c/1426696Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#59025}
-
- 22 Jan, 2019 2 commits
-
-
Ross McIlroy authored
The decision as to whether to optimize an IIFE as oneshot depends on whether it's outer scope is the script scope. During lazy compile, we might have discarded scopes which don't need a context between the IIFE and the script scope, which means we might treat an IIFE as oneshot, even though initial eager compile treated it as non-oneshot. Both bytecode flushing and lazy source positions rely on us generating the same bytecode during lazy compile as eager compile, so we move the decision into the parser where it happens once and is then stored in the SFI for any future lazy compiles. BUG=v8:8395,v8:8510 Change-Id: I88f1e74ad95d47a2636c393ceb1318d7d610055d Reviewed-on: https://chromium-review.googlesource.com/c/1421841Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#58996}
-
Dan Elphick authored
This prevents the bytecode generator generating loads that look for extensions in the global context, which can never succeed and means that lazy and eager bytecode compilation will match. Bug: v8:8510 Change-Id: I51dca62b5d1ee34f8dea82260cf27295ddf427d9 Reviewed-on: https://chromium-review.googlesource.com/c/1425520Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#58983}
-
- 21 Jan, 2019 3 commits
-
-
Toon Verwaest authored
Walk the VariableMap instead of the ast. Change-Id: I03ee9145230bcbfe04c5e31dc8d8b3a98a00a4be Reviewed-on: https://chromium-review.googlesource.com/c/1424865 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58968}
-
Toon Verwaest authored
This allows us to stop tracking variables_ in the preparser. This currently makes us track slightly more variables than neccessary in the case `for (var ...` since `var ... of` needs to check conflicts with out simple catch variables. We should probably track the names through a ScopedPtrList instead of a ZonePtrList anyway. Then it won't matter anymore. Change-Id: I64e3f9ab13af8269456439cf15b0bc4d5b9e5380 Reviewed-on: https://chromium-review.googlesource.com/c/1421360Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58960}
-
Toon Verwaest authored
Use variable tracking from ExpressionScopes rather than the PatternRewriter and PreParserExpression::variables_ to declare variables. We only figure out that variables are non-simple parameters once we see the first non-simple parameter. This still uses the pattern rewriter to make variables non-simple (kLet instead of kVar). Change-Id: I4a4ee4852d667c26806bb24896722cfea3e093f2 Reviewed-on: https://chromium-review.googlesource.com/c/1417630Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58954}
-
- 18 Jan, 2019 1 commit
-
-
Camillo Bruni authored
By using a shared byte buffer on the preparser we can drastically reduce the number of ZoneChunkLists. Each PreparseDataBuilder now explicitly keeps track of all inner builders/functions and writes out the data in consecutive order. Change-Id: I0aada118d869b150108c1f633d9960474ad2f9a1 Reviewed-on: https://chromium-review.googlesource.com/c/1411600 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58926}
-
- 16 Jan, 2019 3 commits
-
-
Toon Verwaest authored
Change-Id: I9195c7ffdc4b841f14701662527c97c9698bd472 Reviewed-on: https://chromium-review.googlesource.com/c/1411888 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58859}
-
Toon Verwaest authored
That makes the declaration in sync with how dynamic references are resolved, avoiding duplicate variable creation in the likely case that the variable is also referenced within the eval. Bug: v8:5112, v8:5135, v8:8693 Change-Id: I0c55495f573fe8b5076b1627c139ff72d1adda74 Also-by: leszeks@chromium.org Reviewed-on: https://chromium-review.googlesource.com/c/1408890 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58850}
-
Leszek Swirski authored
Storing a VariableProxy in declarations means that a declaration and initialisation assignment are tightly coupled to use the same var. In particular, this means that Var declarations in with scopes have to clone the VariableProxy to split the declaration and initializer LHS lookup. This patch changes declarations to point directly to the Variable, not the VariableProxy. This will allow future refactoring to decouple declarations and initialisations. Change-Id: I0baa77bfd12fe175f9521d292740d7d712cffd37 Reviewed-on: https://chromium-review.googlesource.com/c/1406683Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58843}
-
- 15 Jan, 2019 2 commits
-
-
Toon Verwaest authored
The parenthesized flag guarantees that the contents was validated as a possible arrow head. By collapsing a parenthesized expression with an outer binary expression we invalidly kept the flag and invalidly assumed that the collapsed expression was validated. Bug: chromium:921382 Change-Id: I207dcbfd228a1ed216130226fdb7ea045b89b85a Reviewed-on: https://chromium-review.googlesource.com/c/1412172 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58829}
-
Toon Verwaest authored
A sloppy function in a block scope implicitily creates a var in the outer declaration scope if it's not blocked. The assignment created reads the local lexical declaration for the function. The reference introduced automatically takes part in NeedsHoleCheck, requiring the reference to have a valid position. Since the assignment will happen after the local declaration, we give the end_position() of the closure as the position of the reference, so hole checks can be omitted. Bug: chromium:917755 Change-Id: Iee0e042b2463f97f05075f9eec09dac8c6eaf539 Reviewed-on: https://chromium-review.googlesource.com/c/1408991Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58823}
-
- 14 Jan, 2019 1 commit
-
-
Leszek Swirski authored
This removes the iteration protocol from the parser entirely, and opens up future possibilities for more bytecodes implementing the various functions of the protocol. Change-Id: I316b8a92434d3b5f47927408a235ddaecd65d5bb Reviewed-on: https://chromium-review.googlesource.com/c/1403125 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58795}
-
- 10 Jan, 2019 1 commit
-
-
Toon Verwaest authored
This will make it easier to separate out parameter declaration from other other parameter scope information tracking. Change-Id: I8712dd7fc589c84bc1e1a1eab9038af6047b21cd Reviewed-on: https://chromium-review.googlesource.com/c/1403118 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58698}
-
- 09 Jan, 2019 4 commits
-
-
Adam Klein authored
Change-Id: I5b2ec3e8b0d2882465b33fedf62a6eac8f952f93 Reviewed-on: https://chromium-review.googlesource.com/c/1387965Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58679}
-
Camillo Bruni authored
- Add DataGatheringScope::AddSkippableFunction - Rename preparsed_scope_data_builder to preparse_data_builder Change-Id: Ic882de638bed91a6ca4716f88db859410f1450b8 Reviewed-on: https://chromium-review.googlesource.com/c/1400846Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#58673}
-
Leszek Swirski authored
Emit a single destructuring assignment for destructuring declarations, which can be desugared by the bytecode generator. This allows us to remove destructuring desugaring from the parser (specifically, the pattern rewriter) entirely. The pattern "rewriter" is now only responsible for walking the destructuring pattern to declare variables, mark them assigned, and potentially rewrite scopes for the edge case of parameters with a sloppy eval. Note that since the rewriter is no longer rewriting, we have to flip the VariableProxy copying logic for var re-lookup, so that we now pass the new VariableProxy to the variable declaration and leave the original unresolved (rather than passing the original through and rewriting to a new unresolved VariableProxy). This change does have some effect on breakpoint locations, due to some of the available information changing between the parser and bytecode generator, however the new locations appear to be more consistent between assignments and declarations. Change-Id: I3a58dd0a387d2bfb8e5e9e22dde0acc5f440cb82 Reviewed-on: https://chromium-review.googlesource.com/c/1382462 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58670}
-
Toon Verwaest authored
Change-Id: Ib9f51cab17a3ed9e8960857e77fc80a9a08df798 Reviewed-on: https://chromium-review.googlesource.com/c/1400841Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58660}
-
- 08 Jan, 2019 1 commit
-
-
Toon Verwaest authored
Previously we'd always push variable proxies into the unresolved list of the current scope, and possibly delete them from the list later in case they end up being declarations. If variables become assigned, there were two ways to mark them as such: The preparser would marked the variables tracked on the PreParserExpression, and the parser would traverse the LHS AST to find and mark all variables. After this CL, if the scope already knows it's tracking declarations, the variables are never added to the unresolved list in the first place. If the scope is ambigous, it tracks the variable proxies on the side and only adds them to the unresolved list if they end up being references rather than declarations. The same list is now used to bulk mark all LHS variables as assigned; uniformely for both the parser and the preparser. In a next step we'll also use the scope to create declarations. That way we can stop tracking variables_ on PreParserExpression altogether. Change-Id: I6ada37006cc2e066731f29cd4ea314550fc7959f Reviewed-on: https://chromium-review.googlesource.com/c/1397669 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58629}
-
- 07 Jan, 2019 3 commits
-
-
Joyee Cheung authored
This patch sets the name slot of the private name symbols for private fields and display the names in error messages of invalid private field accesses. TBR: adamk@chromium.org Bug: v8:8144 Change-Id: Id34c468e2bddd1c3001517b4d447c7497402df76 Reviewed-on: https://chromium-review.googlesource.com/c/1374332Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#58601}
-
Camillo Bruni authored
We plan to store additional information that is not related to scopes. The new name will reflect this fact better. Change-Id: I4ddb1017bc255e6ad271e4448848ed630f367d5b Reviewed-on: https://chromium-review.googlesource.com/c/1388538 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#58591}
-
Toon Verwaest authored
This simplifies NextArrowFunctionInfo, allows us to Scope::Snapshot::Reparent directly rather than moving it, and allows us to skip reparenting in the simple parameter arrow function cases. This is a reland of https://chromium-review.googlesource.com/c/v8/v8/+/1397664, simply splitting out the arrow-function-name-inferring part. Change-Id: I640d911a9607edc3bbb0e5ff3bf992094e4159e4 Reviewed-on: https://chromium-review.googlesource.com/c/1397701Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58570}
-