- 21 Feb, 2018 1 commit
-
-
Mythri authored
We don't use parser caches anymore and request code caches explicitly using ScriptCompiler::CreateCodeCache. Hence removing the support for both parser cache and code cache options. They are still retained in CompileOptions for backwards compatibility. Apart from the api.cc, no other part should see this option. Bug: chromium:779254, chromium:783124 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ic8ad9afe3fa44bbb5adc71bdde59c0b4057a523d Reviewed-on: https://chromium-review.googlesource.com/916261 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#51416}
-
- 19 Apr, 2017 1 commit
-
-
Adam Klein authored
There's no reason to keep track, for a preparsed function itself, whether that function calls eval. All that matters is that the ancestor scopes are marked as having an inner scope which calls eval. The function will have its "calls eval" bit persisted if/when it's fully parsed. The only "behavioral" change in this patch is the removal of a DCHECK. Bug: v8:6092 Change-Id: I17e396c8a265030fe0ad941707e4a97972e6650b Reviewed-on: https://chromium-review.googlesource.com/481223 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#44732}
-
- 18 Apr, 2017 1 commit
-
-
Marja Hölttä authored
No usage sites are getting the length for uncompiled functions, so we can postpone setting the correct length until after compilation. This way we don't need to produce and store it for skipped inner functions. In the current implementation, getting the function length compiles it (and users rely on it - so the feature is probably not going to go away). BUG=v8:5516 Change-Id: Id8c9a05d2391505a6cde613841094170c9a1b808 Reviewed-on: https://chromium-review.googlesource.com/468927 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#44679}
-
- 10 Apr, 2017 1 commit
-
-
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}
-
- 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}
-
- 29 Mar, 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: 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}
-
- 14 Mar, 2017 1 commit
-
-
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}
-
- 16 Feb, 2017 1 commit
-
-
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}
-
- 09 Jan, 2017 1 commit
-
-
marja authored
Downside: this adds all kinds of weird includes in the .cc files. (See design doc linked in the bug.) BUG=v8:5402 Review-Url: https://codereview.chromium.org/2622503002 Cr-Commit-Position: refs/heads/master@{#42140}
-
- 28 Nov, 2016 1 commit
-
-
jochen authored
They're supposed to be stable across several parse passes, so we'll also store them in the associated SharedFunctionInfos To achieve this, the PreParser and Parser need to generated the same number of FunctionLiterals. To achieve this, we teach the PreParser about desuggaring of class literals. For regular functions, the function IDs are assigned in the order they occur in the source. For arrow functions, however, we only know that it's an arrow function after parsing the parameter list, and so the ID assigned to the arrow function is larger than the IDs assigned to functions defined in the parameter list. This implies that we have to reset the function ID counter to before the parameter list when re-parsing an arrow function. To be able to do this, we store the number of function literals found in the parameter list of arrow functions as well. BUG=v8:5589 Review-Url: https://codereview.chromium.org/2481163002 Cr-Commit-Position: refs/heads/master@{#41309}
-
- 15 Nov, 2016 1 commit
-
-
verwaest authored
This shares the pending_error_handler from the parser to the preparser, allowing the preparser to directly log errors to it. This removes LogMessage from the loggers. ParserLogger::LogMessage was already unused, so this also removes error info from the preparse data altogether. BUG= Review-Url: https://codereview.chromium.org/2502633002 Cr-Commit-Position: refs/heads/master@{#40984}
-
- 07 Nov, 2016 1 commit
-
-
verwaest authored
This - removes the ParserRecorder base class, - devirtualizes the LogFunction and LogMessage functions, - reuses the SingletonLogger for all preparser calls In a subsequent step the preparser should probably log directly to the CompleteParserRecorder rather than indirectly through the singleton logger... BUG= Review-Url: https://codereview.chromium.org/2474393003 Cr-Commit-Position: refs/heads/master@{#40803}
-
- 04 Nov, 2016 1 commit
-
-
verwaest authored
Parameters of a lazily parsed function used to be parsed eagerly, and parameter handling was split between Parser::ParseFunctionLiteral and ParseEagerFunctionBody, leading to inconsistencies. After this CL, we preparse (lazy parse) the parameters of lazily parsed functions. (For arrow functions, we cannot do that ofc.) This is needed for later features (PreParser with scope analysis). -- CL adapted from marja's https://codereview.chromium.org/2411793003/ BUG= Review-Url: https://codereview.chromium.org/2472063002 Cr-Commit-Position: refs/heads/master@{#40771}
-
- 09 Jun, 2016 1 commit
-
-
lpy authored
We ported hashmap.h into libsampler as a workaround before, so the main focus of this patch is to reduce code duplication. This patch moves the hashmap into src/base as well as creates DefaultAllocationPolicy using malloc and free. BUG=v8:5050 LOG=n Review-Url: https://codereview.chromium.org/2010243003 Cr-Commit-Position: refs/heads/master@{#36873}
-
- 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}
-
- 01 Jun, 2015 1 commit
-
-
erikcorry authored
When compiling on a laptop I like to concatenate the small test files. This makes a big difference to compile times. These changes make that easier. R=ulan@chromium.org BUG= Review URL: https://codereview.chromium.org/1163803002 Cr-Commit-Position: refs/heads/master@{#28742}
-
- 18 May, 2015 1 commit
-
-
yangguo authored
Review URL: https://codereview.chromium.org/1130133003 Cr-Commit-Position: refs/heads/master@{#28439}
-
- 09 Mar, 2015 1 commit
-
-
titzer authored
Rationale: separate the inputs and outputs of parsing + analysis from the business of compiling (i.e. generating machine code). BUG= Review URL: https://codereview.chromium.org/974213002 Cr-Commit-Position: refs/heads/master@{#27078}
-
- 20 Feb, 2015 1 commit
-
-
adamk authored
This avoids accidental coercion-to-bool when calling ReportMessage() in the parser (e.g., from pointer types), and as a bonus makes callsites easier to read. Review URL: https://codereview.chromium.org/939303002 Cr-Commit-Position: refs/heads/master@{#26788}
-
- 12 Jan, 2015 1 commit
-
-
marja authored
Instead, we should use Collector::kMinCapacity. R=jochen@chromium.org BUG=v8:3727 LOG=N Review URL: https://codereview.chromium.org/847823002 Cr-Commit-Position: refs/heads/master@{#26030}
-
- 21 Oct, 2014 1 commit
-
-
svenpanne@chromium.org authored
Basically a follow-up to https://codereview.chromium.org/667573005/. LOG=y R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/670673002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24755 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Aug, 2014 1 commit
-
-
bmeurer@chromium.org authored
This way we don't clash with the ASSERT* macros defined by GoogleTest, and we are one step closer to being able to replace our homegrown base/ with base/ from Chrome. R=jochen@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/430503007 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22812 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 10 Jul, 2014 1 commit
-
-
yangguo@chromium.org authored
R=marja@chromium.org, vogelheim@chromium.org Review URL: https://codereview.chromium.org/376223002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22314 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Jun, 2014 1 commit
-
-
jochen@chromium.org authored
Also split v8-core independent methods from checks.h to base/logging.h and merge v8checks with the rest of checks. The CPU::FlushICache method is moved to CpuFeatures::FlushICache RoundUp and related methods are moved to base/macros.h Remove all layering violations from src/libplatform BUG=none R=jkummerow@chromium.org LOG=n Review URL: https://codereview.chromium.org/358363002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22092 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Jun, 2014 1 commit
-
-
mstarzinger@chromium.org authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/333013002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21894 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jun, 2014 1 commit
-
-
jochen@chromium.org authored
- this avoids using relative include paths which are forbidden by the style guide - makes the code more readable since it's clear which header is meant - allows for starting to use checkdeps BUG=none R=jkummerow@chromium.org, danno@chromium.org LOG=n Review URL: https://codereview.chromium.org/304153016 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 27 May, 2014 1 commit
-
-
jochen@chromium.org authored
Verified that arm builds locally. BUG=none TBR=jkummerow@chromium.org LOG=n Review URL: https://codereview.chromium.org/306473004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21512 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 26 May, 2014 2 commits
-
-
jochen@chromium.org authored
TBR=jkummerow@chromium.org Review URL: https://codereview.chromium.org/297303004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21504 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
jochen@chromium.org authored
Since both are jitted on some platforms and depend on codegen, they don't belong to the platform abstraction. At the same time, I can't put them to codegen.h, as this would introduce cyclic dependencies. BUG=none R=jkummerow@chromium.org LOG=n Review URL: https://codereview.chromium.org/302563004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21502 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 May, 2014 1 commit
-
-
marja@chromium.org authored
Removing it seems to be a clear win on mobile: producing symbol data makes cold parsing 20-30% slower, and having symbol data doesn't make warm parsing any faster. Notes: - V8 used to produce symbol data, but because of a bug, it was never used until recently. (See fix https://codereview.chromium.org/172753002 which takes the symbol data into use again.) - On desktop, warm parsing is faster if we have symbol data, and producing it during cold parsing doesn't make parsing substantially slower. However, this doesn't seem to be the case on mobile. - The preparse data (cached data) will now contain only the positions of the lazy functions. BUG= R=dcarney@chromium.org Review URL: https://codereview.chromium.org/261273003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21146 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Apr, 2014 1 commit
-
-
bmeurer@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/259183002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 14 Apr, 2014 1 commit
-
-
marja@chromium.org authored
State of the art: - Chromium doesn't do a separate preparsing phase any more. - We start parsing with Parser, and when it sees a lazy function, it falls back to PreParser for that function. - The symbol data should contain symbols which are *outside* lazy functions. - So Parser should always produce symbol data, and PreParser should never. - Because it's this simple now, we don't need to keep track of "should produce symbol data" (i.e., whether we're inside a lazy func or not). R=ulan@chromium.org BUG= Review URL: https://codereview.chromium.org/222123003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20707 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 01 Apr, 2014 1 commit
-
-
marja@chromium.org authored
For example, invalid left hand sides are reference errors. PreParser didn't use to produce this error ever, so the code for propagating reference errors properly was missing, and reference errors turned into syntax errors. R=rossberg@chromium.org BUG= Review URL: https://codereview.chromium.org/220233006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20408 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 13 Mar, 2014 1 commit
-
-
dcarney@chromium.org authored
R=marja@chromium.org BUG= Review URL: https://codereview.chromium.org/198903002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19892 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Feb, 2014 1 commit
-
-
marja@chromium.org authored
The original code, added by https://codereview.chromium.org/3384003/diff/7001/src/parser.cc 3.5 years ago, failed to write numbers which contain a chunk of 7 zeroes in the middle. The smallest such number is 2^14, so this is a problem if the source file to preparse contains 16384 or more symbols (which happens in the wild). This bug went unnoticed because the symbol data was not used by Parser (see https://codereview.chromium.org/172753002/ for starting to use it again) and there were no tests. R=ulan@chromium.org BUG=346221 LOG=y Review URL: https://codereview.chromium.org/179433004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19538 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Jul, 2013 1 commit
-
-
yangguo@chromium.org authored
R=yangguo@chromium.org Review URL: https://codereview.chromium.org/18509003 Patch from Haitao Feng <haitao.feng@intel.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15510 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 16 Apr, 2013 1 commit
-
-
jkummerow@chromium.org authored
Review URL: https://codereview.chromium.org/13932006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14280 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 28 Feb, 2013 1 commit
-
-
rossberg@chromium.org authored
in preparation of the introduction of ES6 'symbols' (aka private/unique names). The SymbolTable became the StringTable. I also made sure to adapt all comments. The only remaining use of the term "symbol" (other than unrelated uses in the parser and such) is now 'NewSymbol' in the API and the 'V8.KeyedLoadGenericSymbol' counter, changing which might break embedders. The one functional change in this CL is that I removed the former 'empty_string' constant, since it is redundant given the 'empty_symbol' constant that we also had (and both were used inconsistently). R=yangguo@chromium.org BUG= Review URL: https://codereview.chromium.org/12210083 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13781 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 19 May, 2011 1 commit
-
-
lrn@chromium.org authored
Now tests for use of eval, arguments, reserved words and with statement. Review URL: http://codereview.chromium.org/7037024 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7951 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 May, 2011 1 commit
-
-
lrn@chromium.org authored
Handle octal escapes in everything but RegExps. Extend preparser test suite to test whether the preparser reports exceptions to throw. TEST=preparser/* Review URL: http://codereview.chromium.org/6927075 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7804 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-