- 29 Aug, 2019 1 commit
-
-
Leszek Swirski authored
Sloppy eval extends the outer declaration scope's context. This is also true for sloppy eval inside of other sloppy evals -- the outer declaration scope's context is extended rather than the outer sloppy eval's declaration scope. However, we consider eval scopes to also be declaration scopes, for the purposes of strict eval and caching lookup variables. So, we need to make sure that we skip through sloppy eval scopes when marking a scope as calls_sloppy_eval. In fact, we implement this rather as never marking sloppy eval scopes as calls_sloppy_eval, under the assumption that the parent scope will already have been marked calls_sloppy_eval by the outer eval. As a drive-by, fix a TODO to move this logic from calls_sloppy_eval() to RecordEvalCall(), rename the variable to something more meaningful, and make Snapshotting to use a new calls_eval bit on Scope. Bug: chromium:996751 Change-Id: I27ccc7ef429a7ce60b3bb02bf64a3820ae4a2c36 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773247 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63455}
-
- 23 Aug, 2019 1 commit
-
-
Shu-yu Guo authored
- Rename FunctionLiteral::FunctionType to FunctionSyntaxKind. - Re-express IsWrappedBit, IsDeclarationBit, IsAnonymousExpressionBit, and IsNamedExpressionBit in SFI::flags as FunctionSyntaxKind. This frees up 1 bit in SFI::flags. - Re-express the analogous bits in ParseInfo as FunctionSyntaxKind. - Simplifies some logic in the back-and-forth passing of this info between SFI and ParseInfo. - Drive-by fix parsing class member initializations as kAccessorOrMethod. Bug: v8:9644 Change-Id: I6c165d5016d968f5057a32136385ddcdc4a46ef1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1767263Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#63388}
-
- 11 Jun, 2019 1 commit
-
-
Caitlin Potter authored
It was a good flag, but it's time to say goodbye. Let us take a moment to remember the good times we've had during its short time on earth. It shipped in Chrome 74. BUG=v8:8523 R=adamk@chromium.org, mathias@chromium.org, gsathya@chromium.org Change-Id: I37e58360614c0bb3582b8bbfac795d5ed3e5a149 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1641205 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Mathias Bynens <mathias@chromium.org> Auto-Submit: Caitlin Potter <caitp@igalia.com> Cr-Commit-Position: refs/heads/master@{#62099}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 23 May, 2019 1 commit
-
-
Yang Guo authored
NOPRESUBMIT=true TBR=mstarzinger@chromium.org Bug: v8:9247 Change-Id: I4cd6b79a1c2cba944f6f23caed59d4f1a4ee358b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624217 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61790}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 Change-Id: I9bcf2694b449f79cdbe03f5fde59cb21b8cad418 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619758 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#61676}
-
- 15 May, 2019 1 commit
-
-
Yang Guo authored
R=bmeurer@chromium.org, clemensh@chromium.org, jkummerow@chromium.org, sigurds@chromium.org, ulan@chromium.org, verwaest@chromium.org Bug: v8:9247 Change-Id: I153a6bbfc55989fe7a86c052f95c5cb8ee61e841 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613244 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#61557}
-
- 11 Apr, 2019 1 commit
-
-
Toon Verwaest authored
Previously we'd need to eagerly compile upon access to function.length for a lazy function. The preparser already computes function.length, however, so we can store that information in the already available preparse data. Change-Id: I19007c9db5839e8038291fb4433866303935f089 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564190 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#60767}
-
- 26 Feb, 2019 1 commit
-
-
Toon Verwaest authored
GetSymbol previously always internalized the underlying string, even if the preparser does not need it. The most common case where this isn't needed is property name parsing. This seems to speed up preparsing quite a bit. For future reference: Property names in object literals still are needed due to various checks (e.g., get 'constructor', duplicate __proto__, ...); as well as cover grammar parsing (property names can turn into variable references). If we turn all strings that the preparser needs to identify back into contextual keywords we may be able to avoid the former. Change-Id: I549e4600053de3136ca08d4915cc04db36d66a89 Reviewed-on: https://chromium-review.googlesource.com/c/1488764Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59866}
-
- 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}
-
- 30 Jan, 2019 1 commit
-
-
Toon Verwaest authored
Bug: chromium:926819 Change-Id: I44832f8707c413d40e5632ed39b97624059f1fba Reviewed-on: https://chromium-review.googlesource.com/c/1445891Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59198}
-
- 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
-
-
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}
-
Toon Verwaest authored
Change-Id: I2abd9ef9591a5e65dcb3fd0231c8d7467296b576 Reviewed-on: https://chromium-review.googlesource.com/c/1426127Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58990}
-
- 21 Jan, 2019 2 commits
-
-
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}
-
- 15 Jan, 2019 1 commit
-
-
Caitlin Potter authored
Implements https://tc39.github.io/proposal-hashbang/, which simply ignores the first line of a source file if it begins with '#!' (U+0023 U+0021). The test cases are influenced by https://github.com/tc39/test262/pull/1983, which have not been pulled into test262 local-tests due to issues with parseTestRecord. BUG=v8:8523 R=gsathya@chromium.org, adamk@chromium.org, littledan@chromium.org Change-Id: I4ae40222298de768a170c7a1d45fec118ed5713c Reviewed-on: https://chromium-review.googlesource.com/c/1409527 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#58838}
-
- 11 Jan, 2019 2 commits
-
-
Toon Verwaest authored
This unifies the code between parser and preparser, and removes more code from the pattern rewriter. This makes "var x" without assignment and initializer in a loop pessimistically marked as assigned, but that seems pretty unlikely since the variable will just always be undefined. It is also still strictly better than what we had until very recently since any var outside of the function scope used to be marked as assigned. Now we only mark such variables as assigned. Change-Id: Icb37ab249b2a79c2d57a5769bdb964b435cebf62 Reviewed-on: https://chromium-review.googlesource.com/c/1405228Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58736}
-
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
Keep track of loop nesting depth on FunctionState and use that to decide whether to mark var as assigned. That also fixes the weird cornercase where a loop body can have multiple expressions due to multiple declarations with independent initializers in a single var-statement. Change-Id: Ia24affde29e22e9464448fd390062f6dd983faf2 Reviewed-on: https://chromium-review.googlesource.com/c/1405037Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58707}
-
- 09 Jan, 2019 1 commit
-
-
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}
-
- 08 Jan, 2019 2 commits
-
-
Camillo Bruni authored
Always precheck that the PreparseData has data before serializing it. Drive-by-fix: - rename preparsed_scope_data_builder_ to preparse_data_builder_ Change-Id: I8e709af8f69db44e03caa9132f06a7b8c906bfdb Reviewed-on: https://chromium-review.googlesource.com/c/1387305Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#58635}
-
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 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 1 commit
-
-
Toon Verwaest authored
That way we can drop PatternRewriter::scope_ and just use parser_->scope() instead. Change-Id: I66137d3ff8e7b805afc7108fd2d55537f69f11e6 Reviewed-on: https://chromium-review.googlesource.com/c/1387500Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58432}
-
- 19 Dec, 2018 3 commits
-
-
Toon Verwaest authored
Later we want to automatically declare the parameters while parsing, which moves the declaration before body parsing anyway. This is just a step in that direction, making sure that it works. Change-Id: I0645269aa26643de138848c599cfe5d1ad4bf32c Reviewed-on: https://chromium-review.googlesource.com/c/1384319Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#58376}
-
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 3 commits
-
-
Camillo Bruni authored
Avoiding malloc and unique_ptr seems to have positive effects on a representative facebook and cnn workload. This makes arrow functions and eager functions potentially more expensive since the DataGatheringScope is now always stack-allocated and only the full initialization happens conditionally. Change-Id: Ibf1c1308a7db464f7c5d2bafd61560e4cabf0ce9 Reviewed-on: https://chromium-review.googlesource.com/c/1382733Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#58340}
-
Toon Verwaest authored
This changes how rewind upon preparser abort works. It now rewinds to the start of the parameter scope. In the case of "function X(" it is before the "(". In the case of arrow functions it's before the start of the arrow function. This allows us to reparse the arrow function from the start so all parameters are declared properly. Bug: v8:2728, v8:7390 Change-Id: I1c40056a49ec198560e63cd73949a59221ee0401 Reviewed-on: https://chromium-review.googlesource.com/c/1382736Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#58332}
-
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}
-
- 27 Nov, 2018 1 commit
-
-
Toon Verwaest authored
Pushing unresolved variables at the front was an optimization for the case where we didn't have an end pointer. That forces us to do an O(<new elements>) walk to rescope variables. The implementation was more generic and even did O(<all elements>). Now that we have an end pointer we can simply push at the end and MoveTail which is O(1). Change-Id: I65cd5752b432223d95cd529452a064d8dcc812e1 Reviewed-on: https://chromium-review.googlesource.com/c/1351010 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#57868}
-
- 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}
-
- 14 Nov, 2018 1 commit
-
-
Toon Verwaest authored
Change-Id: I3d07bb2d1ae8c77a6b245f5e4ca6f755e2617730 Reviewed-on: https://chromium-review.googlesource.com/c/1335698Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57512}
-
- 13 Nov, 2018 2 commits
-
-
Toon Verwaest authored
Change-Id: I19e23a1e91631a21d55bb5a42f1f538a655478f8 Reviewed-on: https://chromium-review.googlesource.com/c/1332233 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#57467}
-
Toon Verwaest authored
We're fetching the symbols anyway, so we might as well use those instead in the preparser. Change-Id: Ie937c755690cdd7b15e8486aa9680d530eff602e Reviewed-on: https://chromium-review.googlesource.com/c/1332296Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57460}
-
- 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}
-