- 04 Jun, 2015 1 commit
-
-
arv authored
We used to only store the uses_super_property in the preparse data logger. Let the logger use NeedsHomeObject instead. BUG=v8:3768 LOG=N R=wingo, adamk Review URL: https://codereview.chromium.org/1164073003 Cr-Commit-Position: refs/heads/master@{#28806}
-
- 18 May, 2015 1 commit
-
-
yangguo authored
Review URL: https://codereview.chromium.org/1130133003 Cr-Commit-Position: refs/heads/master@{#28439}
-
- 21 Apr, 2015 1 commit
-
-
svenpanne authored
Baby steps towards saner #includes... Review URL: https://codereview.chromium.org/1051393003 Cr-Commit-Position: refs/heads/master@{#27958}
-
- 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}
-
- 13 Feb, 2015 1 commit
-
-
arv authored
The preparser needs to log the usage of super properties and then update the scope when we create the function later. BUG=v8:3888 LOG=N R=dslomov@chromium.org, marja Review URL: https://codereview.chromium.org/923683002 Cr-Commit-Position: refs/heads/master@{#26642}
-
- 04 Feb, 2015 1 commit
-
-
marja authored
This enables adding more language modes in the future. For maximum flexibility, LanguageMode is a bitmask, so we're not restricted to use a sequence of language modes which are progressively stricter, but we can express the language mode as combination of features. For now, LanguageMode can only be "sloppy" or "strict", and there are STATIC_ASSERTS in places which need to change when more modes are added. LanguageMode is a bit like the old LanguageMode when "extended" mode was still around (see https://codereview.chromium.org/8417035 and https://codereview.chromium.org/181543002 ) except that it's transmitted through all the layers (there's no StrictModeFlag). BUG= Review URL: https://codereview.chromium.org/894683003 Cr-Commit-Position: refs/heads/master@{#26419}
-
- 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
-
- 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
-
- 09 May, 2014 1 commit
-
-
ishell@chromium.org authored
1) runtime/references checks temporarily disabled (56 items left) 2) other errors fixed R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/277913002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21222 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 2 commits
-
-
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
-
dcarney@chromium.org authored
R=marja@chromium.org BUG= Review URL: https://codereview.chromium.org/198583003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19883 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Mar, 2014 1 commit
-
-
rossberg@chromium.org authored
- Merge LanguageMode and StrictModeFlag enums - Make harmony-scoping depend only on strict mode - Free some bits on the way - Plus additional clean-up and renaming R=ulan@chromium.org BUG= Review URL: https://codereview.chromium.org/181543002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19800 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
-
- 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
-
- 12 Mar, 2012 1 commit
-
-
erik.corry@gmail.com authored
Review URL: https://chromiumcodereview.appspot.com/9600009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11007 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Nov, 2011 1 commit
-
-
keuchel@chromium.org authored
This CL introduces a third mode next to the non-strict (henceforth called 'classic mode') and 'strict mode' which is called 'extended mode' as in the current ES.next specification drafts. The extended mode is based on the 'strict mode' and adds new functionality to it. This means that most of the semantics of these two modes coincide. The 'extended mode' is entered instead of the 'strict mode' during parsing when using the 'strict mode' directive "use strict" and when the the harmony-scoping flag is active. This should be changed once it is fully specified how the 'extended mode' is entered. This change introduces a new 3 valued enum LanguageMode (see globals.h) corresponding to the modes which is mostly used by the frontend code. This includes the following components: * (Pre)Parser * Compiler * SharedFunctionInfo, Scope and ScopeInfo * runtime functions: StoreContextSlot, ResolvePossiblyDirectEval, InitializeVarGlobal, DeclareGlobals The old enum StrictModeFlag is still used in the backend when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes: * SetProperty runtime function, Delete builtin * StoreIC and KeyedStoreIC * StubCache Review URL: http://codereview.chromium.org/8417035 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 27 Oct, 2011 1 commit
-
-
keuchel@chromium.org authored
Review URL: http://codereview.chromium.org/8396040 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9818 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Jun, 2011 1 commit
-
-
ager@chromium.org authored
Propagate strict mode information from pre-parser to parser for lazily compiled functions. R=lrn@chromium.org BUG=v8:1436 TEST=mjsunit/regress/regress-1436.js Review URL: http://codereview.chromium.org/7044054 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8227 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 May, 2011 2 commits
-
-
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
-
svenpanne@chromium.org authored
header which uses BASE_EMBEDDED and/or AllStatic. Note that still only 45 out of 135 headers in src/ can be used stand-alone, but at least this is a little bit more than before... Review URL: http://codereview.chromium.org/6931031 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7798 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 May, 2011 1 commit
-
-
kmillikin@chromium.org authored
Try to make sure that accessors.h, data-flow.h, list-inl.h, and scopeinfo.h are included only where needed, but without introducing implicit dependencies. Review URL: http://codereview.chromium.org/6903175 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7756 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Jan, 2011 1 commit
-
-
lrn@chromium.org authored
Revision 6309 changed which functions were considered lazy. That also means that there must be preparse data for now non-lazy functions. BUG= TEST= Review URL: http://codereview.chromium.org/6270002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6359 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 Dec, 2010 1 commit
-
-
lrn@chromium.org authored
Make preparser keep its symbol text itself instead of relying on the scanner. Review URL: http://codereview.chromium.org/6075005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6115 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 23 Nov, 2010 1 commit
-
-
lrn@chromium.org authored
Extracted preparse-data specification and logging classes. Review URL: http://codereview.chromium.org/5166006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@5877 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-