- 27 Aug, 2018 1 commit
-
-
Peter Marshall authored
This reverts commit 133a6815. Reason for revert: Regresses parsing time Original change's description: > [cleanup] Replace ZoneList with ZoneVector for parser reported_errors_ > > We use a ZoneVector because we do a fair amount of random access e.g. > in ExpressionClassifier::Accumulate() so the vector is better suited > than ZoneChunkList as it has constant time random access. > > Bug: v8:6333 > Change-Id: I83e1de60ee8fe319cfa5ce77fc5f5f86beb5307d > Reviewed-on: https://chromium-review.googlesource.com/1054672 > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#55315} TBR=neis@chromium.org,petermarshall@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:6333 Change-Id: Ib89f0aa1f27b7d6dbbf21af60ed7d1bcd2c0b7d3 Reviewed-on: https://chromium-review.googlesource.com/1189803Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#55427}
-
- 22 Aug, 2018 1 commit
-
-
Peter Marshall authored
We use a ZoneVector because we do a fair amount of random access e.g. in ExpressionClassifier::Accumulate() so the vector is better suited than ZoneChunkList as it has constant time random access. Bug: v8:6333 Change-Id: I83e1de60ee8fe319cfa5ce77fc5f5f86beb5307d Reviewed-on: https://chromium-review.googlesource.com/1054672Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#55315}
-
- 20 Aug, 2018 1 commit
-
-
Adam Klein authored
ParseErrorType is never passed to ExpressionClassifier, so there's no need to store it in the Error struct (we can always use the Parser's default of SyntaxError). Also simplify the handling of non-simple parameter detection, which was stored in a two-bit function_properties_ field that was only being used for this purpose. Bug: v8:8015 Change-Id: I198e8285cbafee650614d1ff5bb434fe9fd2a338 Reviewed-on: https://chromium-review.googlesource.com/1180525Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#55234}
-
- 02 Feb, 2018 1 commit
-
-
jgruber authored
This check verifies that all .h files in the src/ directory have an include guard of the form #ifndef V8_PATH_TO_FILE_H_ #define V8_PATH_TO_FILE_H_ // ... #endif // V8_PATH_TO_FILE_H_ The check can be skipped with a magic comment: // PRESUBMIT_INTENTIONALLY_MISSING_INCLUDE_GUARD Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I0a7b96abec289ad60f64ba8418f1892a6969596d Reviewed-on: https://chromium-review.googlesource.com/897487Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#51079}
-
- 15 Dec, 2017 1 commit
-
-
Caitlin Potter authored
This gets rid of all the RewriteNonPattern gunk in the parser and expression classifier, and removes one use of RewritableExpression. This borrows pieces from several other CLs of mine which are currently open, and includes a new and modernized abstraction for dealing with iterators in BytecodeGenerator (so, this CL adds that, moves code from BuildGetIterator around, and makes some minor changes to yield* which should maintain compatability with the old behaviour). This also implements a portion of the changes to the iteration protocol (implemented fully in https://chromium-review.googlesource.com/c/v8/v8/+/687997), but only for the spread operator in Array Literals (the rest will follow). BUG=v8:5940, v8:3018 R=rmcilroy@chromium.org, marja@chromium.org, adamk@chromium.org TBR=adamk@chromium.org Change-Id: Ifc494d663d8e46066a439c3541c33f0243726234 Reviewed-on: https://chromium-review.googlesource.com/804396 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#50138}
-
- 13 Nov, 2017 1 commit
-
-
Adam Klein authored
Since each Array literal containing a spread is individually queued for rewriting, there's no need for an AstVisitor here: a simple linear pass through the queue is sufficient. This patch deletes AstExpressionRewriter and all the machinery supporting it in the AST. This code was built with the idea of using it as a general expression rewriting mechanism in the parser, but those use cases never materialized, and Array spread remains the only thing that used this code. Bug: v8:6092 Change-Id: I754c4883099e840881b005f20216f86e57721d5a Reviewed-on: https://chromium-review.googlesource.com/765051Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#49337}
-
- 06 Oct, 2016 1 commit
-
-
adamk authored
R=ishell@chromium.org Review-Url: https://codereview.chromium.org/2395003002 Cr-Commit-Position: refs/heads/master@{#40053}
-
- 24 Sep, 2016 1 commit
-
-
littledan authored
This patch fixes the logic of finding the location of a duplicate parameter error in arrow functions by only looking at the error if it exists. This should address a TSAN error. Further, an UNREACHABLE() statement is inserted somewhere in the ExpressionClassifier code to make future similar bugs easier to find. BUG=v8:4483 Review-Url: https://codereview.chromium.org/2365693004 Cr-Commit-Position: refs/heads/master@{#39701}
-
- 01 Sep, 2016 1 commit
-
-
nikolaos authored
This patch removes the explicit classifier parameters from all parsing methods and makes expression classifiers implicit in the (pre)parser's implementation. In this way, the implementation is simplified and a proper stack of classifiers is enforced. R=adamk@chromium.org,littledan@chromium.org BUG= LOG=N Review-Url: https://codereview.chromium.org/2289663002 Cr-Commit-Position: refs/heads/master@{#39068}
-
- 26 Aug, 2016 3 commits
-
-
nikolaos authored
A minor change in the logic of expression classifiers that eliminates the use for MergeNonPatterns. R=adamk@chromium.org, littledan@chromium.org BUG= LOG=N Review-Url: https://codereview.chromium.org/2275313002 Cr-Commit-Position: refs/heads/master@{#38934}
-
nikolaos authored
This patch: 1. Removes the unecessary inheritance of ParserBaseTraits<Impl> in ParserBase<Impl>. 2. Flattens ParserBaseTraits<Impl> and renames it to ParserTypes<Impl>. The Traits parameter/member is renamed to Types. 3. Removes unecessary v8::internal:: qualifications from parser types. R=adamk@chromium.org, marja@chromium.org BUG= LOG=N Review-Url: https://codereview.chromium.org/2279773002 Cr-Commit-Position: refs/heads/master@{#38927}
-
adamk authored
They are both accumulated at the same time, and either one already triggered an error in ValidateExpression. Basically, there were no disjoint uses of these two error types. Review-Url: https://codereview.chromium.org/2268173005 Cr-Commit-Position: refs/heads/master@{#38922}
-
- 25 Aug, 2016 3 commits
-
-
adamk authored
Previously the calls to ExpressionClassifier::Accumulate() each chose slightly different sets of productions to accumulate, and it turned out that these were in some cases broader than needed and in some cases less broad. The existence of some grab-bag production bitmasks like ExpressionClassifier::ExpressionProductions made this situation more error-prone (for example, that production was missing AsyncArrowFormalParametersProduction). This patch removes all "grab-bags" besides AllProductions. In some of the places where code was using those grab-bags for convenience, it switches them to use negation of AllProductions. In other, specifically those having to do with expressions that are disallowed anywhere in a sub-expression of a parameter list, I've added a new method on ExpressionClassifier to centralize the logic. The aforementioned centralization/addition of AsyncArrowFormalParametersProduction fixes several cases where we were failing to report an error for 'await' in some contexts; I've added those test cases. The patch also narrows all cases to exactly the set or productions necessary, with a comment on each explaining the choice. BUG=v8:4483 Review-Url: https://codereview.chromium.org/2271063002 Cr-Commit-Position: refs/heads/master@{#38918}
-
vogelheim authored
DuplicateFinder isn't actually used by the Scanner, except for one convenience function which we should probably remove, also. BUG= Review-Url: https://codereview.chromium.org/2281443002 Cr-Commit-Position: refs/heads/master@{#38904}
-
nikolaos authored
This patch moves the following methods from the traits objects to the (pre)parser implementation objects: - AddFormalParameter - AddParameterInitializationBlock - DeclareFormalParameter - ExpressionListToExpression - GetNonPatternList - GetReportedErrorList - IsTaggedTemplate - MaterializeUnspreadArgumentsLiterals - NoTemplateTag - ParseArrowFunctionFormalParameterList - ReindexLiterals - SetFunctionNameFromIdentifierRef - SetFunctionNameFromPropertyName It moves the Void method from the preparser traits object to the preparser implementation object. It also removes the traits zone method and replaces it with that of ParserBase, which it turns to public. After all this, the traits objects contain just typedefs and the delegate methods are no more necessary. R=adamk@chromium.org, marja@chromium.org BUG= LOG=N Review-Url: https://codereview.chromium.org/2277843002 Cr-Commit-Position: refs/heads/master@{#38892}
-
- 23 Aug, 2016 1 commit
-
-
adamk authored
The only two places where these Forgive methods were called was in ParseAssignmentExpression just at the time we were calling Accumulate(). So instead of Forgiving, we can simply not accumulate the bits that would have been forgiven. Also slightly restructures the nearby code in ParseAssignmentExpression, and removes the use of non-const references in ExpressionClassifier. Review-Url: https://codereview.chromium.org/2267223002 Cr-Commit-Position: refs/heads/master@{#38839}
-
- 22 Aug, 2016 1 commit
-
-
adamk authored
The following code was previously accepted: async function f() { let g = (await) => {}; } But per the spec, using 'await' is disallowed in arrow parameters by an early error rule (just as 'yield' is disallowed in arrow params inside generators). There was special logic in ParseUnaryExpression which seems to have been there only to allow that case. Having removed it, we get a SyntaxError in the right cases anyway when ParseUnaryExpression chokes on whatever illegal token follows 'await' in the cases this code previously handled. Also removes the unnecessary AsyncBindingPatternProduction enum value. R=caitp@igalia.com, littledan@chromium.org BUG=v8:4483 Review-Url: https://codereview.chromium.org/2258313002 Cr-Commit-Position: refs/heads/master@{#38802}
-
- 20 Aug, 2016 1 commit
-
-
gsathya authored
This patch subsumes CoverInitializedNameProduction to create an ObjectLiteralProduction which is now used to report the duplicate proto error as well. This patch also changes ObjectLiteralChecker::CheckProperty to record an ObjectLiteralProduction error instead of bailing out immediately. Once we realize that we're in a pattern, we rewind the error, otherwise we report the error. BUG=v8:5121 Review-Url: https://codereview.chromium.org/2255353002 Cr-Commit-Position: refs/heads/master@{#38764}
-
- 19 Aug, 2016 1 commit
-
-
adamk authored
Also removed the "StandardProductions" enum value as its name is unhelpful in deciding when to use it (and it only had a single reference). R=gsathya@chromium.org Review-Url: https://codereview.chromium.org/2260183003 Cr-Commit-Position: refs/heads/master@{#38763}
-
- 13 Jun, 2016 1 commit
-
-
nikolaos authored
It seems that I forgot to remove the DCHECK when refactoring this function, even though the comment had it right. It also seems that this is hard to trigger. The minimal example I found, after fuzzer's bug, was: eval, x[eval] R=adamk@chromium.org BUG=chromium:619476 LOG=N Review-Url: https://codereview.chromium.org/2058413002 Cr-Commit-Position: refs/heads/master@{#36929}
-
- 10 Jun, 2016 1 commit
-
-
nikolaos authored
This patch attempts to reduce the (stack) memory footprint of expression classifiers. Instead of keeping space in each classifier for all possible error messages that will (potentially) be reported, if an expression turns out to be a pattern or a non-pattern, such error messages are placed in a list shared by the FunctionState and each classifier keeps a couple of indices in this list. This requires that classifiers are used strictly in a stack-based fashion, which is also in line with my previous patch for revisiting non-pattern rewriting. R=adamk@chromium.org BUG=chromium:528697 Review-Url: https://codereview.chromium.org/1708193003 Cr-Commit-Position: refs/heads/master@{#36897}
-
- 16 May, 2016 1 commit
-
-
caitpotter88 authored
BUG=v8:4483 LOG=Y R=littledan@chromium.org, adamk@chromium.org Review-Url: https://codereview.chromium.org/1841543003 Cr-Commit-Position: refs/heads/master@{#36261}
-
- 04 May, 2016 1 commit
-
-
ishell authored
Unlike previous implementation where the 'continue' keyword was a feature of a return statement the keyword is now recognized as a part of expression. Error reporting was significantly improved. --harmony-explicit-tailcalls option is now orthogonal to --harmony-tailcalls so we can test both modes at the same time. This CL also adds %GetExceptionDetails(exception) that fetches hidden |start_pos| and |end_pos| values from the exception object. BUG=v8:4915 LOG=N Review-Url: https://codereview.chromium.org/1928203002 Cr-Commit-Position: refs/heads/master@{#36024}
-
- 10 Mar, 2016 1 commit
-
-
rossberg authored
R=mstarzinger@chromium.org,bmeurer@chromium.org,adamk@chromium.org BUG=v8:3956 LOG=Y Review URL: https://codereview.chromium.org/1773653002 Cr-Commit-Position: refs/heads/master@{#34669}
-
- 19 Feb, 2016 3 commits
-
-
nikolaos authored
of non-pattern expressions, according to the (internally circulated) design document. Details to be provided here. 1. RewritableAssignmentExpression has been renamed to RewritableExpression. It is a wrapper for AST nodes that wait for some potential rewriting (that may or may not happen). Also, Is... and As... macros now see through RewritableExpressions. 2. The function state keeps a list of rewritable expressions that must be rewritten only if they are used as non-pattern expressions. 3. Expression classifiers are now templates, parameterized by parser traits. They keep some additional state: a pointer to the list of non-pattern rewritable expressions. It is important that expression classifiers be used strictly in a stack fashion, from now on. 4. The RewriteNonPattern function has been simplified. BUG=chromium:579913 LOG=N Committed: https://crrev.com/7f5c864a6faf2b957b7273891e143b9bde35487c Cr-Commit-Position: refs/heads/master@{#34154} Review URL: https://codereview.chromium.org/1702063002 Cr-Commit-Position: refs/heads/master@{#34162}
-
machenbach authored
Revert of Non-pattern rewriting revisited (patchset #3 id:40001 of https://codereview.chromium.org/1702063002/ ) Reason for revert: [Sheriff] This makes jsfunfuzz unhappy: https://build.chromium.org/p/client.v8/builders/V8%20Fuzzer/builds/7681 Original issue's description: > This patch implements an alternative approach to the rewriting > of non-pattern expressions, according to the (internally circulated) > design document. Details to be provided here. > > 1. RewritableAssignmentExpression has been renamed to RewritableExpression. > It is a wrapper for AST nodes that wait for some potential rewriting > (that may or may not happen). Also, Is... and As... macros now see > through RewritableExpressions. > > 2. The function state keeps a list of rewritable expressions that must be > rewritten only if they are used as non-pattern expressions. > > 3. Expression classifiers are now templates, parameterized by parser > traits. They keep some additional state: a pointer to the list of > non-pattern rewritable expressions. It is important that expression > classifiers be used strictly in a stack fashion, from now on. > > 4. The RewriteNonPattern function has been simplified. > > BUG=chromium:579913 > LOG=N > > Committed: https://crrev.com/7f5c864a6faf2b957b7273891e143b9bde35487c > Cr-Commit-Position: refs/heads/master@{#34154} TBR=rossberg@chromium.org,bmeurer@chromium.org,titzer@chromium.org,nikolaos@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:579913 Review URL: https://codereview.chromium.org/1712203002 Cr-Commit-Position: refs/heads/master@{#34158}
-
nikolaos authored
of non-pattern expressions, according to the (internally circulated) design document. Details to be provided here. 1. RewritableAssignmentExpression has been renamed to RewritableExpression. It is a wrapper for AST nodes that wait for some potential rewriting (that may or may not happen). Also, Is... and As... macros now see through RewritableExpressions. 2. The function state keeps a list of rewritable expressions that must be rewritten only if they are used as non-pattern expressions. 3. Expression classifiers are now templates, parameterized by parser traits. They keep some additional state: a pointer to the list of non-pattern rewritable expressions. It is important that expression classifiers be used strictly in a stack fashion, from now on. 4. The RewriteNonPattern function has been simplified. BUG=chromium:579913 LOG=N Review URL: https://codereview.chromium.org/1702063002 Cr-Commit-Position: refs/heads/master@{#34154}
-
- 04 Dec, 2015 1 commit
-
-
caitpotter88 authored
Attempt #<really big number> Parses, and lazily rewrites Destructuring Assignment expressions. The rewriting strategy involves inserting a placeholder RewritableAssignmentExpression into the AST, whose content expression can be completely rewritten at a later time. Lazy rewriting ensures that errors do not occur due to eagerly rewriting nodes which form part of a binding pattern, thus breaking the meaning of the pattern --- or by eagerly rewriting ambiguous constructs that are not immediately known BUG=v8:811 LOG=Y R=adamk@chromium.org, bmeurer@chromium.org, rossberg@chromium.org Review URL: https://codereview.chromium.org/1309813007 Cr-Commit-Position: refs/heads/master@{#32623}
-
- 26 Nov, 2015 1 commit
-
-
rossberg authored
Moves all files related to AST and scopes into ast/, and all files related to scanner & parser to parsing/. Also eliminates a couple of spurious dependencies. R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/1481613002 Cr-Commit-Position: refs/heads/master@{#32351}
-
- 15 Oct, 2015 1 commit
-
-
littledan authored
When the checker was added prohibiting lexical binding called let, certain error propagation was not implemented properly. This patch fixes that issue, which fixes error checking for cases such as let [let] BUG=v8:4403 R=adamk LOG=N Review URL: https://codereview.chromium.org/1409613003 Cr-Commit-Position: refs/heads/master@{#31289}
-
- 05 Oct, 2015 1 commit
-
-
littledan authored
This patch prohibits lexical bindings from being called 'let', even in sloppy mode, following the ES2015 specification. The change affects multiple cases of lexical bindings, including simple let/const declarations and both kinds of for loops. var and legacy const bindings still permit the name to be let, including in destructuring cases. Tests are added to verify, though some cases are commented out since they led to (pre-existing) crashes. BUG=v8:4403 R=adamk LOG=Y Review URL: https://codereview.chromium.org/1371263003 Cr-Commit-Position: refs/heads/master@{#31115}
-
- 30 Sep, 2015 1 commit
-
-
mstarzinger authored
This enables linter checking for "readability/namespace" violations during presubmit and instead marks the few known exceptions that we allow explicitly. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1371083003 Cr-Commit-Position: refs/heads/master@{#31019}
-
- 28 Aug, 2015 1 commit
-
-
wingo authored
R=adamk@chromium.org LOG=N BUG=v8:4397 Review URL: https://codereview.chromium.org/1320673007 Cr-Commit-Position: refs/heads/master@{#30431}
-
- 26 Aug, 2015 1 commit
-
-
conradw authored
TC39 agreed to disallow "use strict" directives in function body when non-simple parameter lists are used. This is a continuation of caitp's CL https://codereview.chromium.org/1281163002/ with some refactorings removed for now. Still TODO: there is a lot of duplication between the is_simple field of FormalParametersBase and the NonSimpleParameter property ExpressionClassifier keeps track of. It should be possible to remove the former with a minor refactoring of arrow function parsing. This will be attempted in a follow-up CL. BUG= LOG=N Review URL: https://codereview.chromium.org/1300103005 Cr-Commit-Position: refs/heads/master@{#30388}
-
- 11 Aug, 2015 1 commit
-
-
mstarzinger authored
This is the first step of turning the v8.h file into a normal header instead of an include-the-world header. The new rule is that no other header files are allowed to include v8.h, which is enforced by DEPS. Also the number of includes inside the v8.h file has been drastically reduced. Basically the last missing piece is the inclusion of the big objects-inl.h file. This in turn makes many headers follow the IWYU principle. R=bmeurer@chromium.org,hpayer@chromium.org,titzer@chromium.org Review URL: https://codereview.chromium.org/1282503003 Cr-Commit-Position: refs/heads/master@{#30102}
-
- 07 Aug, 2015 1 commit
-
-
rossberg authored
Fixes the use of eval calls in strict parameter lists in particular. R=adamk@chromium.org BUG=v8:811 LOG=N Review URL: https://codereview.chromium.org/1276273002 Cr-Commit-Position: refs/heads/master@{#30074}
-
- 14 Jul, 2015 1 commit
-
-
littledan authored
Duplicate parameters are banned both overall in strict mode and also in arrow functions. Our error message for both cases blamed strict mode, which is confusing. This patch fixes the message to point to arrow functions as a possible source as well. R=wingo, adamk LOG=N Review URL: https://codereview.chromium.org/1236863008 Cr-Commit-Position: refs/heads/master@{#29662}
-
- 10 Jun, 2015 1 commit
-
-
wingo authored
R=dslomov@chromium.org LOG=N BUG= Review URL: https://codereview.chromium.org/1174543003 Cr-Commit-Position: refs/heads/master@{#28896}
-
- 09 Jun, 2015 1 commit
-
-
dslomov authored
Pushed the detection logic down to ParseAndClassifyIdentifier in preparation to having patterns in parameter positions. R=arv@chromium.org,rossberg@chromium.org,wingo@igalia.com BUG=v8:811 LOG=N Review URL: https://codereview.chromium.org/1170153003 Cr-Commit-Position: refs/heads/master@{#28876}
-