- 30 Jan, 2019 1 commit
-
-
Leszek Swirski authored
Change-Id: I0895d9b9131a0c06edd3d1359c080b8b6830d236 Reviewed-on: https://chromium-review.googlesource.com/c/1443060Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#59190}
-
- 28 Jan, 2019 2 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}
-
- 25 Jan, 2019 2 commits
-
-
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}
-
- 23 Jan, 2019 1 commit
-
-
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}
-
- 22 Jan, 2019 2 commits
-
-
Adam Klein authored
This follows the "CRTP" pattern used elsewhere in the Parser rather than a branch on IsPreParser(). Also merge GetUnexpectedTokenMessage() into ReportUnexpectedTokenAt(). Change-Id: I8eaa5cc3230c4660624a48c705f80d1a60a2710b Reviewed-on: https://chromium-review.googlesource.com/c/1423094Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#59006}
-
Toon Verwaest authored
Change-Id: I907ace62da903dd57cb86b608c0f96ac49623976 Reviewed-on: https://chromium-review.googlesource.com/c/1426130 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#58991}
-
- 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 2 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}
-
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 1 commit
-
-
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}
-
- 11 Jan, 2019 1 commit
-
-
Leszek Swirski authored
Change-Id: I021776d10dd8ef4bf406f286ee233aff9680a0ec Reviewed-on: https://chromium-review.googlesource.com/c/1384315 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58730}
-
- 10 Jan, 2019 1 commit
-
-
Toon Verwaest authored
Change-Id: I3acb492f1b9930e574bfbad063f54b20eab26bf1 Reviewed-on: https://chromium-review.googlesource.com/c/1405033Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58705}
-
- 09 Jan, 2019 1 commit
-
-
Toon Verwaest authored
It's anyway only read in case of simple parameters. In that case pattern is guaranteed to be a VariableProxy, from which we can read the name as well. Change-Id: Ie340064453594ab4f84b1d0223506801635c289d Reviewed-on: https://chromium-review.googlesource.com/c/1402782 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#58668}
-
- 08 Jan, 2019 2 commits
-
-
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}
-
Sathya Gunasekaran authored
Change-Id: Ieed2a202cbbceaad8a598d359fcbd02944edfdb4 Reviewed-on: https://chromium-review.googlesource.com/c/1398685 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58605}
-
- 07 Jan, 2019 2 commits
-
-
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}
-
Ross McIlroy authored
Real world websites don't benifit from aborting preparsing to eagerly compile long trivial functions, and it adds unecessary complexity to the parser and doesn't work well with bytecode flushing, so we remove it. Perf Sheriffs: this is expected to regress the MandreelLatency benchmark on Octane. BUG=v8:8395 Change-Id: Ia60cd67d4dd100376d2a366939a1d2a97cbc2b0d Reviewed-on: https://chromium-review.googlesource.com/c/1394297 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58568}
-
- 21 Dec, 2018 2 commits
-
-
Adam Klein authored
Presumably this was obsoleted when this functionality moved to the BytecodeGenerator. Change-Id: I691fdaa01610ea050511825b5ad1f3ba4963421c Reviewed-on: https://chromium-review.googlesource.com/c/1387991Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#58453}
-
Toon Verwaest authored
Change-Id: I9446a73bb47b11e2d161a4678638b7618ce52b9a Reviewed-on: https://chromium-review.googlesource.com/c/1387490Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58427}
-
- 19 Dec, 2018 2 commits
-
-
Toon Verwaest authored
Now we just check for each variable declared in the parameter scope whether it occurs as a lexical variable in the body scope. This way the preparser will also identify them. Bug: v8:2728, v8:5064 Change-Id: I9fd96590fa431de0656c85295fd31af9b36f2e32 Reviewed-on: https://chromium-review.googlesource.com/c/1384225Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58375}
-
Toon Verwaest authored
- Directly declares the special catch variable from the parser-base. - Tracks Scope on PreParserBlock and finds conflicting lexical declarations by simply walking the VariableMap of the block inserted for the pattern; or the catch variable in case of identifier. - This also enables throwing errors for duplicate let in the preparser. We may have to back that out if it breaks something. Bug: v8:2728, v8:7828 Change-Id: Id2eea62062533eb99cd6670c42a4b1da87139008 Reviewed-on: https://chromium-review.googlesource.com/c/1382095Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58353}
-
- 18 Dec, 2018 1 commit
-
-
Toon Verwaest authored
Since it's explicit what we're tracking, we can immediately throw errors in certain cases, and ignore irrelevant errors. We don't need to use the classifier itself to track "let let", since we know whether we're parsing a "let". Errors that were previously (almost) always accumulated are now immediately pushed to the scopes that care (parameter initialization errors). This CL drops avoiding allocation of classified errors, at least for now, but that doesn't affect performance anymore since we don't aggressively blacklist anymore. Classified errors are even less likely with the more precise approach. ParseAssignmentExpression doesn't introduce its own scope immediately, but reuses the outer scope. Rather than using full ExpressionClassifiers + Accumulate to separate expressions/patterns from each other while keeping track of the overall error state, this now uses an explicit AccumulationScope. When we parse (async) arrow functions we introduce new scopes that track that they may be (async) arrow functions. We track StrictModeFormal parameters in 2 different ways if it isn't immediately certain that it is a strict-mode formal error: Either directly on the (Pre)ParserFormalParameters, or on the NextArrowFunctionInfo in the case we're not yet certain that we'll have an arrow function. In the latter case we don't have a FormalParameter object yet, and we'll copy it over once we know we're parsing an arrow function. The latter works because it's not allowed to change strictness of a function with non-simple parameters. Design doc: https://docs.google.com/document/d/1FAvEp9EUK-G8kHfDIEo_385Hs2SUBCYbJ5H-NnLvq8M/ Change-Id: If4ecd717c9780095c7ddc859c8945b3d7d268a9d Reviewed-on: https://chromium-review.googlesource.com/c/1367809 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#58307}
-
- 30 Nov, 2018 1 commit
-
-
Toon Verwaest authored
- Rely more heavily on Token::IsValidIdentifier. - Deal with IsLet() when it's possibly a lexical declaration. - Remove ENUM from the default IsAnyIdentifier range. - Always pre-check whether IsAnyIdentifier before classifying identifiers. Change-Id: I55eae6ff65dc306b466fa29d233c715e85bc3854 Reviewed-on: https://chromium-review.googlesource.com/c/1356514Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#57977}
-
- 26 Nov, 2018 2 commits
-
-
Camillo Bruni authored
Bug: v8:8238 Change-Id: I0f3b8336a63bb4e1859997b7b9f150f1e7b2d988 Reviewed-on: https://chromium-review.googlesource.com/c/1346338 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#57830}
-
Toon Verwaest authored
No-Tree-Checks: true No-Try: true Change-Id: If9e39eb64db24e7d7dd2ae639d95f750aef04210 Reviewed-on: https://chromium-review.googlesource.com/c/1350119 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#57817}
-
- 22 Nov, 2018 1 commit
-
-
Toon Verwaest authored
This simplifies the ExpressionClassifier a bit again, making it a little more understandable. Change-Id: I57bdd871b10409ea04b33748609160f2b40a498a Reviewed-on: https://chromium-review.googlesource.com/c/1348431Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57753}
-
- 21 Nov, 2018 1 commit
-
-
Toon Verwaest authored
Use the parser's IsValidReferenceExpression as a likely-succeeding precheck. Slightly optimizes IsEvalOrArguments in the preparser and IsIdentifier for the parser (we now have FailureExpression everywhere); and replaces IsObjectLiteral||IsArrayLiteral by IsValidPattern. Change-Id: I7e9684485c0ce454e640800566eb4b0a24c6bfc8 Reviewed-on: https://chromium-review.googlesource.com/c/1345995 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#57682}
-
- 19 Nov, 2018 1 commit
-
-
Joyee Cheung authored
This patch implements the parsing of private methods in the stage 3 proposal https://tc39.github.io/proposal-private-methods - Adds a --harmony-private-methods flag - Parse the private methods/accessors The design doc is in https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit?usp=sharing This patch only makes sure the syntax parses, doesn't implement the semantics. Bug: v8:8330 Change-Id: I9007b3b3dd6a0df35db7bb14f38f1a38d52bc663 Reviewed-on: https://chromium-review.googlesource.com/c/1329706 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57615}
-
- 12 Nov, 2018 1 commit
-
-
Toon Verwaest authored
Now that identifiers in the preparser also carry their string, we can simply check that rather than relying on a weird "keyword". Dropping __proto__ as a keyword allows us to delist '_' as keyword character. Change-Id: I775df25f77a84de92a60790ca665f16d52abf4bf Reviewed-on: https://chromium-review.googlesource.com/c/1329692 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#57427}
-
- 09 Nov, 2018 1 commit
-
-
Toon Verwaest authored
The current implementation isn't very helpful anyway if we ever really want this. Change-Id: Iad4132734980937aee462a1613d47887383585a0 Reviewed-on: https://chromium-review.googlesource.com/c/1328928Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57388}
-
- 07 Nov, 2018 1 commit
-
-
Toon Verwaest authored
That allows us to keep on running further without explicit RETURN_IF Bug: v8:8363, v8:7926 Change-Id: If1424a1dae656ac725a8443b09ea1b8cc25dfcb1 Reviewed-on: https://chromium-review.googlesource.com/c/1322953Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57319}
-
- 05 Nov, 2018 2 commits
-
-
Toon Verwaest authored
In particular FunctionLiteral body. Now clients cannot use function_literal->body() == nullptr anymore to figure out whether it was preparsed; but have to check the eager compile hint. Change-Id: Ia0d3a6b51c6fb7e803157e98a9d224224e03c8a7 Reviewed-on: https://chromium-review.googlesource.com/c/1317811Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57246}
-
Takuto Ikuta authored
I will enable /Zc:DllexportInlines- flags for faster build time on windows. But the flag makes clang's -Wundefined-inline check more strict as a secondary effect. Actually, having inline function specifier for the function not defined in header file seems bit strange. Let me remove inline specifier from such functions. Bug: chromium:857548, chromium:901709 Change-Id: Ic06d10e2445cfedc7af67b72154f93a51ac26853 Reviewed-on: https://chromium-review.googlesource.com/c/1186017 Commit-Queue: Takuto Ikuta <tikuta@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57229}
-
- 31 Oct, 2018 1 commit
-
-
Toon Verwaest authored
Change-Id: I44ac330e093a4cbca4540a1948c9365c08f73914 Reviewed-on: https://chromium-review.googlesource.com/c/1310293Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#57183}
-