- 10 Apr, 2017 2 commits
-
-
Marja Hölttä authored
Previously we didn't produce all data that we need for creating sensemaking FunctionLiterals for the skipped functions. Test in https://chromium-review.googlesource.com/c/457037 . BUG=v8:5516 Change-Id: I1fd02c1109ef6e07e93da131062fd5101a8c8de9 Reviewed-on: https://chromium-review.googlesource.com/469767 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#44515}
-
Wiktor Garbacz authored
This is inital work in order to utilize CompilerDispatcher in parallel parsing. BUG=v8:6093 Change-Id: I6aae4f32ddb2314585d09039c1c5d7e658dc896f Reviewed-on: https://chromium-review.googlesource.com/469709Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Cr-Commit-Position: refs/heads/master@{#44509}
-
- 05 Apr, 2017 1 commit
-
-
Marja Hölttä authored
There's no need to set it so early - it's only needed when the function has really been parsed. This way we don't need to produce and store it for skipped inner functions. BUG=v8:5516 Change-Id: Ibf59a8acb886ea3de9be140431a334a03b408f5b Reviewed-on: https://chromium-review.googlesource.com/461827 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44410}
-
- 04 Apr, 2017 1 commit
-
-
Caitlin Potter authored
Remove destructuring assignments (parsed during arrow function formal parameters) from queue for rewriting if parsing a lazy top-level arrow function. Built ontop of https://chromium-review.googlesource.com/c/464769/ BUG=chromium:706234, chromium:706761, v8:6182 R=marja@chromium.org, adamk@chromium.org, vogelheim@chromium.org Change-Id: Ib35196b907350d1d78e4c3fcbf4cc971bf200948 Reviewed-on: https://chromium-review.googlesource.com/465415 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44393}
-
- 31 Mar, 2017 2 commits
-
-
Franziska Hinkelmann authored
Add the source position to variables if they are parameters. Collect type information for parameters and return values. Index the types by their corresponding source position. For the types of return values, use the function end as source position. Sample output for a function with 2 parameters (at source position 252 and 258, and function end at 443) ************* Function: testFunction 252: Object number string number 258: undefined boolean undefined undefined 443: Object number string number ************* BUG=v8:5933 Change-Id: I3b8749afcac706c1834146abf1b5b4a3fd130fb6 Reviewed-on: https://chromium-review.googlesource.com/461919Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#44299}
-
bmeurer authored
Rewrite returns in derived constructors to only replace undefined with this, and otherwise just return the value, and let the construct stub builtin throw an exception if the result is a primitive instead of a JSReceiver. R=yangguo@chromium.org TBR=marja@chromium.org BUG=chromium:706642 Review-Url: https://codereview.chromium.org/2788033002 Cr-Commit-Position: refs/heads/master@{#44288}
-
- 29 Mar, 2017 2 commits
-
-
Caitlin Potter authored
- Introduce new struct AsyncGeneratorRequest, which holds information pertinent to resuming execution of an AsyncGenerator, such as the Promise associated with the async generator request. It is intended to be used as a singly linked list, and holds a pointer to the next item in te queue. - Introduce JSAsyncGeneratorObject (subclass of JSGeneratorObject), which includes several new internal fields (`queue` which contains a singly linked list of AsyncGeneratorRequest objects, and `await_input` which contains the sent value from an Await expression (This is necessary to prevent function.sent (used by yield*) from having the sent value observably overwritten during execution). - Modify SuspendGenerator to accept a set of Flags, which indicate whether the suspend is for a Yield or Await, and whether it takes place on an async generator or ES6 generator. - Introduce interpreter intrinsics and TF intrinsic lowering for accessing the await input of an async generator - Modify the JSGeneratorStore operator to understand whether or not it's suspending for a normal yield, or an AsyncGenerator Await. This ensures appropriate registers are stored. - Add versions of ResumeGeneratorTrampoline which store the input value in a different field depending on wether it's an AsyncGenerator Await resume, or an ordinary resume. Also modifies whether debug code will assert that the generator object is a JSGeneratorObject or a JSAsyncGeneratorObject depending on the resume type. BUG=v8:5855 R=bmeurer@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org, littledan@chromium.org, neis@chromium.org TBR=marja@chromium.org Change-Id: I9d58df1d344465fc937fe7eed322424204497187 Reviewed-on: https://chromium-review.googlesource.com/446961 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#44240}
-
Marja Hölttä authored
There's no need to set it so early - it's only needed when the function has really been parsed. This way we don't need to produce and store it for skipped inner functions. BUG=v8:5516 Change-Id: Ida2abd44b494030771b5663a8eb326edb0a53b72 Reviewed-on: https://chromium-review.googlesource.com/461160Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44235}
-
- 28 Mar, 2017 2 commits
-
-
Daniel Vogelheim authored
Introduce 'contextual keyword' tokens, which are parsed as identifiers but in some contexts are treated by the parser like proper keywords. These are usually keywords introduced by recent ECMAScript versions, which for reasons of backwards compatibility are still permissible as regular identifiers in most contexts. Current usage is to check for Token::IDENTIFIER and then do a string compare. With this change the initial scan will scan them as usual, but will then record the token as IDENTIFIER plus a secondary token with the 'contextual' value. BUG=v8:6902 Change-Id: I6ae390382998cf756a23720bd481cb9c0eb78a72 Reviewed-on: https://chromium-review.googlesource.com/459479 Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44189}
-
Marja Hölttä authored
As far as I can see, we have had this bug as long as destructuring assignments have been there (i.e., this is not regression). The problem was that Parser::DoParseFunction parsed the arrow function parameters but didn't rewrite the destructuring assignments in them. BUG=chromium:704811 Change-Id: I0b1424e7d5103eda6efd51b403fe81a4ee235e01 Reviewed-on: https://chromium-review.googlesource.com/459618 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#44177}
-
- 24 Mar, 2017 2 commits
-
-
Daniel Vogelheim authored
Removes the AstString super-class and makes the two sub-classes stand-alone. That also removes the slightly awkward implementation of a super-class with dynamically dispatched behaviour, except it was manually implemented because virtual function calls were considered expensive. BUG=v8:6902 Change-Id: I079a2372557aa17ee839efcaddb9b7fe86e38b4d Reviewed-on: https://chromium-review.googlesource.com/458428 Commit-Queue: Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44104}
-
Wiktor Garbacz authored
A step towards removing isolate from ParseInfo. Removing isolate from ParseInfo will make it easier to create and execute parse tasks on background threads. BUG=v8:6093 Change-Id: If5e7ba2f76f9f8422c26f47c9f0eb5b197114b25 Reviewed-on: https://chromium-review.googlesource.com/458000Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Cr-Commit-Position: refs/heads/master@{#44089}
-
- 23 Mar, 2017 1 commit
-
-
Wiktor Garbacz authored
It was removed so that Parser::DeserializeScopeChain does not have to get it from ParseInfo. Only a small step in direction of removing isolate from ParseInfo. BUG=v8:6093 Change-Id: Iaaf92dc6eb5ec9c4efc05ac73666fbc66e0ed8c1 Reviewed-on: https://chromium-review.googlesource.com/457999 Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Cr-Commit-Position: refs/heads/master@{#44057}
-
- 22 Mar, 2017 2 commits
-
-
Caitlin Potter authored
Just the front-end side of https://chromium-review.googlesource.com/c/446961/. Adds support for parsing AsyncGeneratorExpression, AsyncGeneratorDeclaration, and AsyncGeneratorMethod, as well as parser tests. BUG=v8:5855 R=neis@chromium.org, marja@chromium.org, littledan@chromium.org Change-Id: I70e1a9681f22573f29292eacb4b9f57f9a38e2b2 Reviewed-on: https://chromium-review.googlesource.com/447117Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#44040}
-
Caitlin Potter authored
While the primary use-case for Suspend nodes is the Yield expression, there are other uses as well: Await expressions, and the initial suspend of Generators, which returns an object matching the Iterator protocol. "Suspend" is a better representation of the spec text (closer to the spec text for the values of [[GeneratorState]] and [[AsyncGeneratorState]]), and can make it easier to understand the meaning of what I had previously called Yield::is_normal() (now Suspend::is_yield()). Changes requested as part of https://chromium-review.googlesource.com/c/447117/ BUG= R=neis@chromium.org, adamk@chromium.org TBR=bmeurer@chromium.org, paul.lind@imgtec.com, joransiu@ca.ibm.com, weiliang.lin@intel.com Change-Id: Ic6f15b04fff091c20f26526391b967287c06f6bf Reviewed-on: https://chromium-review.googlesource.com/455583Reviewed-by:
Caitlin Potter <caitp@igalia.com> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#44038}
-
- 21 Mar, 2017 1 commit
-
-
Marja Hölttä authored
Rebase of https://chromium-review.googlesource.com/446336 was broken. Didn't fail any tests because the feature is behind a flag. BUG= Change-Id: I6009bfac27aa896e20446f002f5db707aab7e34c Reviewed-on: https://chromium-review.googlesource.com/457040 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#43984}
-
- 17 Mar, 2017 2 commits
-
-
Marja Hölttä authored
The data needed to be modified a bit to actually allow skipping over functions based on it. In particular, we need to allow skipping over an unknown inner scope structure (in the previous stage, we just had tests comparing the data against some baseline truth, so it wasn't needed). also removing the current "skip functions based on preparse data" logic, since preparser data is not used any more. At a later stage, I'll consider plugging the preparser-scope-analysis-data into that pipeline (so I don't want to remove the full code yet). Integration to the various forms of compilation is still incomplete; this CL integrates just enough to get the minimal example to pass: (function foo() { function preparsed() { var var1 = 10; function skip_me() { print(var1); } return skip_me; } return preparsed; })()()(); BUG=v8:5516 Change-Id: I0d24b4c3b338f7e6b6c3bf7cf2c1ceb29608e2f2 Reviewed-on: https://chromium-review.googlesource.com/446336 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#43908}
-
Wiktor Garbacz authored
Parse tasks are still WIP so there is really no benefit turning them on. Turn off irrelevant tests. Fix duplicate parameters inverted logic. Fix use_counts tracking. Fix language mode, super_property, evals. Fix modules and stack overflow. BUG=v8:6093 Change-Id: I8567b36eef7b9de6799789e7520810bde9c86e5b Reviewed-on: https://chromium-review.googlesource.com/455916 Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#43903}
-
- 14 Mar, 2017 2 commits
-
-
Wiktor Garbacz authored
BUG=v8:6093 Change-Id: Icdc0706a3af23fbf538021a7e80fedaf0b5ae866 Reviewed-on: https://chromium-review.googlesource.com/453699 Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#43784}
-
Wiktor Garbacz authored
BUG=v8:6093 Change-Id: I7268abd56769d4cbaefdaa901c532871837cc47e Reviewed-on: https://chromium-review.googlesource.com/452340Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Cr-Commit-Position: refs/heads/master@{#43782}
-
- 13 Mar, 2017 1 commit
-
-
yangguo authored
The switch statement itself is part of the switch block. However, the source position of the statement is outside of the block. This leads to confusion for the debugger, if the switch block pushes a block context: the current context is a block context, but the scope analysis based on the current source position tells the debugger that we should be outside the scope, so we should have the function context. R=marja@chromium.org BUG=v8:6085 Review-Url: https://codereview.chromium.org/2744213003 Cr-Commit-Position: refs/heads/master@{#43744}
-
- 10 Mar, 2017 1 commit
-
-
wiktorg authored
BUG= R=marja@chromium.org Review-Url: https://codereview.chromium.org/2738153003 Cr-Commit-Position: refs/heads/master@{#43716}
-
- 03 Mar, 2017 3 commits
-
-
Marja Hölttä authored
Materialized literal removal is a follow up to https://chromium-review.googlesource.com/443246 In addtion, remove ParserBase::Checkpoint; it was for restoring materialized literal counts and expected property counts, but actually the expected property count tracking was incorrect ("this" in arrow function param list binds to the outside, so it's correct without the checkpoint): (a, b = this.c = 0) => { } BUG= Change-Id: Ic097f6d2e7cb235166fb3a76af3bf5584bc167f0 Reviewed-on: https://chromium-review.googlesource.com/449733Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#43579}
-
Georg Neis authored
The pattern of creating a hidden catch scope occurs several times, so define a helper for it. BUG= Change-Id: I5831378341d86d41bfb015bd3e687183cc79ac20 Reviewed-on: https://chromium-review.googlesource.com/448559 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#43574}
-
Georg Neis authored
This is always the single variable declared in the catch scope. BUG= Change-Id: I05ccc48f57394268432c9b5b8c76f9db1b3b6312 Reviewed-on: https://chromium-review.googlesource.com/448041Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#43571}
-
- 28 Feb, 2017 5 commits
-
-
Georg Neis authored
BUG= Change-Id: Id77205450d286be228b493deb69e1489a1e12895 Reviewed-on: https://chromium-review.googlesource.com/445906 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#43501}
-
Georg Neis authored
BUG=v8:6022 Change-Id: I54205cb3ecc2dd31ed62e55726f0ec5fcd202c30 Reviewed-on: https://chromium-review.googlesource.com/446349 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#43500}
-
Adam Klein authored
Previously, we over-approximated Scope::scope_calls_eval_ in arrow functions: if either the outer scope or the arrow function parameters had a direct eval call, we marked both scopes as calling eval. This over-approximation kept getting us into trouble, though, especially when eager or lazy parsing would disagree about the "calls eval" bit. This patch instead tracks eval calls accurately, using a boolean on Scope::Snapshot that is reset as appropriately depending on whether a particular AssignmentExpression turned out to be an arrow parameter list or not. BUG=chromium:691687 Change-Id: I527dc59b4d32a2797805ff26dc9f70b1311377b2 Reviewed-on: https://chromium-review.googlesource.com/446094 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#43499}
-
Georg Neis authored
This is more useful than always returning undefined. BUG=v8:1569,v8:5978 Change-Id: Id10cf87f7865db1a85de412460eaead4e4bf3b62 Reviewed-on: https://chromium-review.googlesource.com/446846Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#43498}
-
Marja Hölttä authored
With the params (a, b, ...c) the param / variable declaration order used to be "temp, temp, c, a, b". Now it is "temp, temp, a, b, c" as you'd expect. This makes it easier for PreParser to match the parameter order of Parser. R=verwaest@chromium.org BUG=v8:5516 Change-Id: I79da04ef3f812bf52c032bed6263c009fecb7988 Reviewed-on: https://chromium-review.googlesource.com/447677Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#43490}
-
- 24 Feb, 2017 1 commit
-
-
Marja Hölttä authored
This is also needed so that PreParser doesn't need to gather more data for arrow function params in order to create the uninteresting varblock scopes matching the scopes created in Parser::BuildParameterInitializationBlock. This cancels the changes in https://chromium-review.googlesource.com/c/444747 which make PreParser create uninteresting scopes for the normal (non-arrow) function "eval in default param" case. R=vogelheim@chromium.org BUG=v8:5516 Change-Id: I8957ac0796d8738c63492f7928bca6f00e4b4241 Reviewed-on: https://chromium-review.googlesource.com/446339Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#43411}
-
- 22 Feb, 2017 1 commit
-
-
bakkot authored
This implements the proposal at https://github.com/tc39/proposal-template-literal-revision staged behind a flag --harmony-template-escapes. The proposal allows invalid octal, unicode, and hexadecimal escape sequences to appear in tagged template literals, instead of being a syntax error. These have a 'cooked' value of 'undefined', but are still accessible through the 'raw' property. BUG=v8:5546 Review-Url: https://codereview.chromium.org/2665513002 Cr-Commit-Position: refs/heads/master@{#43384}
-
- 20 Feb, 2017 2 commits
-
-
Marja Hölttä authored
Handle eval in default parameters. BUG=v8:5516 R=vogelheim@chromium.org Change-Id: Ib6543a4aef9a3cc9636e65d0337bc269c8a079dc Reviewed-on: https://chromium-review.googlesource.com/444747 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#43328}
-
Toon Verwaest authored
By now lazy allocation of block scopes probably doesn't make that much sense anymore, since the memory overhead significantly reduced. Not indirecting scope() over ScopeState is faster, which is more important at this point. BUG=v8:5209 Change-Id: I2968f01252769e7b1198a0a0876765a06ab0d3bd Reviewed-on: https://chromium-review.googlesource.com/445025Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#43313}
-
- 16 Feb, 2017 3 commits
-
-
jwolfe authored
For functions declared in source code, the .toString() representation will be an excerpt of the source code. * For functions declared with the "function" keyword, the excerpt starts at the "function" or "async" keyword and ends at the final "}". The previous behavior would start the excerpt at the "(" of the parameter list, and prepend a canonical `"function " + name` or similar, which would discard comments and formatting surrounding the function's name. Anonymous functions declared as function expressions no longer get the name "anonymous" in their toString representation. * For methods, the excerpt starts at the "get", "set", "*" (for generator methods), or property name, whichever comes first. Previously, the toString representation for methods would use a canonical prefix before the "(" of the parameter list. Note that any "static" keyword is omitted. * For arrow functions and class declarations, the excerpt is unchanged. For functions created with the Function, GeneratorFunction, or AsyncFunction constructors: * The string separating the parameter text and body text is now "\n) {\n", where previously it was "\n/*``*/) {\n" or ") {\n". * At one point, newline normalization was required by the spec here, but that was removed from the spec, and so this CL does not do it. Included in this CL is a fix for CreateDynamicFunction parsing. ')' and '`' characters in the parameter string are no longer disallowed, and Function("a=function(", "}){") is no longer allowed. BUG=v8:4958, v8:4230 Review-Url: https://codereview.chromium.org/2156303002 Cr-Commit-Position: refs/heads/master@{#43262}
-
Marja Hölttä authored
Patch adopted from mvstanton@ ( https://codereview.chromium.org/2657413002/ ) BUG= Change-Id: I4296b3d5694116e250a6bb88296fbed0f0c444e6 Reviewed-on: https://chromium-review.googlesource.com/443246Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#43238}
-
neis authored
This is in order to prevent accidental bugs in desugarings. R=adamk@chromium.org BUG=v8:5636 Review-Url: https://codereview.chromium.org/2693313002 Cr-Commit-Position: refs/heads/master@{#43237}
-
- 15 Feb, 2017 2 commits
-
-
caitp authored
When --harmony-async-iteration is enabled, it is now possible to use the for-await-of loop, which uses the Async Iteration protocol rather than the ordinary ES6 Iteration protocol. the Async-from-Sync Iterator object is not implemented in this CL, and so for-await-of loops will abort execution if the iterated object does not have a Symbol.asyncIterator() method. Async-from-Sync Iterators are implemented seperately in https://codereview.chromium.org/2645313003/ BUG=v8:5855, v8:4483 R=neis@chromium.org, littledan@chromium.org, adamk@chromium.org Review-Url: https://codereview.chromium.org/2637403008 Cr-Commit-Position: refs/heads/master@{#43224}
-
Marja Hölttä authored
- Different places used is_simple to mean different things; renamed one. - No need to do Scope::SetHasNoSimpleParameters multiple times. - Normally we create VAR parameters with a name, or (for destructuring parameters), TEMPORARY parmeters with an empty name. *Except* for destructuring rest parameters; then we create VAR a parameter with an empty name. This CL makes the empty-named parameter TEMPORARY instead of VAR. - This makes it clear that Parser::DeclareFormalParameters declares exactly those params which Parser::BuildParamerterInitializationBlock doesn't declare. - This unification doesn't change any functionality, but it makes sense to do since I'll need to make PreParser emulate what Parser does; this way I don't need to emulate the weird behavior. BUG=v8:5501 Change-Id: Ifa6c116bc5908f4e03a36e74f47558888d1582bd Reviewed-on: https://chromium-review.googlesource.com/443106Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#43220}
-
- 13 Feb, 2017 1 commit
-
-
adamk authored
R=neis@chromium.org Review-Url: https://codereview.chromium.org/2690723002 Cr-Commit-Position: refs/heads/master@{#43144}
-