v8/test/mjsunit/regress/regress-903874.js

// Copyright 2018 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.

var code = "function f(" + ("{o(".repeat(10000));
assertThrows(code, SyntaxError);
[parser] Check stackoverflow in ParseBindingPattern Bug: chromium:903874 Change-Id: If9828ae206b9bc1407e7d3f217d5fb894a4fe747 Reviewed-on: https://chromium-review.googlesource.com/c/1329688 Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57420} 2018-11-12 08:23:14 +00:00			`// Copyright 2018 the V8 project authors. All rights reserved.`
			`// Use of this source code is governed by a BSD-style license that can be`
			`// found in the LICENSE file.`

			`var code = "function f(" + ("{o(".repeat(10000));`
[parser] Replacing ExpressionClassifier with ExpressionScope that knows what it's tracking 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} 2018-12-17 09:28:27 +00:00			`assertThrows(code, SyntaxError);`