- 11 May, 2021 1 commit
-
-
Luis Fernando Pardo Sixtos authored
This change adds support for `const` redeclaration on REPL mode with the semantincs recommended in the design doc: 1) REPL scripts should not be able to reassign bindings to `const` variables. 2) Re-declaring `const` variables of page scripts is not allowed in REPL scripts. 3) Re-declearing `const` variables is not allowed in the same REPL script. 4) `const` re-declaration is allowed across separate REPL scripts. 5) Old references to previously declared variables get updated with the new value, even those references from within optimized functions. Design doc: https://goo.gle/devtools-const-repl Bug: chromium:1076427 Change-Id: Ic73d2ae7fcfbfc1f5b58f61e0c3c69e9c4d85d77 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2865721Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Luis Fernando Pardo Sixtos <lpardosixtos@microsoft.com> Cr-Commit-Position: refs/heads/master@{#74510}
-
- 08 May, 2020 1 commit
-
-
Joyee Cheung authored
Bug: v8:5368, v8:8330 Change-Id: I237541223289546b8de031f905d42bb9234c8448 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2184649 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67667}
-
- 02 Mar, 2020 1 commit
-
-
Leszek Swirski authored
Remove OffThreadHandle, HandleOrOffThreadHandle, and HandleFor, and make the OffThreadIsolate allocate "real" Handles. Rather than using the main-thread Isolate's handle scopes, these off-thread Handles are backed by a Zone, which is tied to the lifetime of the nearest OffThreadHandleScope. Eventually, we'll likely want to merge the implementation of OffThreadHandleScope and HandleScope, but currently the latter is too tightly coupled to the main thread to do so. Bug: chromium:1011762 Change-Id: I2a6361931fe3f90a7bef4cc28ee42155fa8d062f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071865Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66516}
-
- 10 Feb, 2020 1 commit
-
-
Leszek Swirski authored
Make Scope allocation and ScopeInfo creation Isolate-templated. This includes making SourceTextModuleInfo allocation templated -- modules aren't currently streamed off-thread, but will hopefully be in the future, so this future-proofs them against that. Bug: chromium:1011762 Change-Id: I8954e08e8e81489eb821b5f62ec35a5be31fce09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043790Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#66197}
-
- 04 Feb, 2020 1 commit
-
-
Leszek Swirski authored
The Factory/OffThreadFactory allows us to cleanly separate object construction behaviour between main-thread and off-thread in a syntactically consistent way (so that methods templated on the factory type can be made to work on both). However, there are cases where we also have to access the Isolate, for handle creation or exception throwing. So far we have been pushing more and more "customization points" into the factories to allow these factory-templated methods to dispatch on this isolate behaviour via these factory methods. Unfortunately, this is an increasing layering violation between Factory and Isolate, particularly around exception handling. Now, we introduce an OffThreadIsolate, analogous to Isolate in the same way as OffThreadFactory is analogous to Factory. All methods which were templated on Factory are now templated on Isolate, and methods which used to take an Isolate, and which were recently changed to take a templated Factory, are changed/reverted to take a templated Isolate. OffThreadFactory gets an isolate() method to match Factory's. Notably, FactoryHandle is changed to "HandleFor", where the template argument can be either of the Isolate type or the Factory type (allowing us to dispatch on both depending on what is available). Bug: chromium:1011762 Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66101}
-
- 16 Jan, 2020 1 commit
-
-
Leszek Swirski authored
Add support for internalizing an AstValueFactory using the off-thread factory. Includes adding ConsString support to OffThreadFactory. This introduces a Handle union wrapper, which is used in locations that can store a Handle or an OffThreadHandle. This is used in this patch for the internalized "string" field of AST strings, and will be able to be used for other similar fields in other classes (e.g. the ScopeInfo handle in Scope, object boilerplate descriptor handles, the inferred name handle on FunctionLiterals, etc.). It has a Factory-templated getter which returns the appropriate handle for the factory, and a debug-only tag to make sure the right getter is used at runtime. This union wrapper currently decomposes implicitly to a Handle if the getter is not called, to minimise code changes, but this implicit conversion will likely be removed for clarity. Bug: chromium:1011762 Change-Id: I5dd3a7bbdc483b66f5ff687e0079c545b636dc13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993971 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65816}
-
- 27 Dec, 2019 1 commit
-
-
Daniel Clifford authored
In the process: * Rework the Torque definition of ScopeInfo to enable direct field-style access of ScopeFlags, removing some dead code in the process. * Allow implicit FromConstexpr conversion from subtypes of 'constexpr A' to other types. This makes it possible/easy to convert constexpr versions of enums to other types, since the constexpr version of the enum isn't addressable. It's namespace isn't a valid namespace and is an implementation detail anyway. * Cleanup LanguageMode: Language mode is now an enum and directly mirrors the C++-side definition rather than being a Smi. With the changes above, a new type LanguageModeSmi is introduced that is the Smi representation of LanguageMode that can be implicitly casted from constexpr LanguageMode values. Change-Id: I190412f95e02905f445d149883fbf1f2b8ed757b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977159 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65561}
-
- 15 Nov, 2019 1 commit
-
-
Dan Elphick authored
utils.h itself is fairly large and contains lots of unrelated functions as well as having a fair number of dependencies itself, so this splits bounds checking and bit field operations into their own headers in base and replaces uses of utils.h with the more appropriate header where possible. (Also fixes some cases where other headers were previously brought in transitively). Bug: v8:9810, v8:8912 Change-Id: I76c53f953848a57e2c5bfad6ce45abcd6d2a4f1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916604Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#64983}
-
- 06 Nov, 2019 1 commit
-
-
Simon Zünd authored
Design doc: bit.ly/v8-repl-mode This CL adds a new REPL mode that can be used via DebugEvaluate::GlobalREPL. REPL mode only implements re-declaration of 'let' bindings at the moment. Example: REPL Input 1: let x = 21; REPL Input 2: let x = 42; This would normally throw a SyntaxError, but works in REPL mode. The implementation is done by: - Setting a 'repl mode' bit on {Script}, {ScopeInfo}, {ParseInfo} and script {Scope}. - Each global let declaration still gets a slot reserved in the respective {ScriptContext}. - When a new REPL mode {ScriptContext} is created, name clashes for let bindings are not reported as errors. - Declarations, loads and stores for global let in REPL mode are now "load/store global" instead of accessing their respective context slot directly. This causes a lookup in the ScriptContextTable where the found slot for each name is guaranteed to be the same (the first one). Bug: chromium:1004193, chromium:1018158 Change-Id: Ia6ab526b9f696400dbb8bfb611a4d43606119a47 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876061 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64793}
-
- 24 Sep, 2019 1 commit
-
-
Dan Elphick authored
Always unmark arrowhead parameters as assigned directly after their initialization as the parser doesn't know when it first sees the "assignment" that it may be in an arrowhead. Bug: chromium:1003403, v8:8510 Change-Id: Iad5a4136d5ec06331fc43b81a809fd72cee2dd65 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1815131 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63947}
-
- 11 Sep, 2019 1 commit
-
-
Joyee Cheung authored
This patch uses a bit in the Variable bit fields to distinguish static private names from instance private names, so that we can check the conflicts of private accessors that are complementary but with different staticness in the parser, and use this information later when generating code for checking static brands for private method access. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: I8d70600e594e3d07f77ea519751b7ca2e0de87b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781010Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#63677}
-
- 05 Sep, 2019 1 commit
-
-
Dan Elphick authored
Since const variables are immutable, ignore SetMaybeAssigned for them. Bug: chromium:999450, chromium:1000170, v8:8510 Change-Id: Idc1b71677b3d03bb63cc025017c119710b8f392d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782170 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#63579}
-
- 05 Aug, 2019 1 commit
-
-
Clemens Hammacher authored
Instead of exposing a {kNext} constant to be used to construct the next bitfield, expose a templatized {Next} type alias. This ensures that the storage type is the same for all bitfields created this way. It's also shorter. Apart from the expected changes in the code base, the AST node classes are changed to expose a {NextBitField} templated type alias instead of a {kNextBitFieldIndex} constant. They thus follow the same pattern as {BitField} itself. R=jkummerow@chromium.org, mstarzinger@chromium.org, verwaest@chromium.org Bug: v8:9396 Change-Id: I70a1b0bd71cde694ec53444de0ca55e4cf0a3836 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728615Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63068}
-
- 30 Jul, 2019 1 commit
-
-
Joyee Cheung authored
This patch adds: - VariableMode::kPrivateMethod - VariableMode::kPrivateSetterOnly - VariableMode::kPrivateGetterOnly - VariableMode::kPrivateGetterAndSetter And replace the previous RequiresBrandCheckFlag by inferring whether the brand check is required from these VariableModes. It is then possible to check duplicate non-complementary accessors in the parsers and throw early errors, and allow complementary accessors to be associated with the same private name variable. This patch also adds the following AssignType: - PRIVATE_METHOD - PRIVATE_GETTER_ONLY - PRIVATE_SETTER_ONLY - PRIVATE_GETTER_AND_SETTER corresponding to the new VariableModes so that it's possible to generate specialized code for different type of private accessor declarations. Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit Bug: v8:8330 Change-Id: I0fb61b1be248630d1eadd74fb16d7d64a421f4c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695204 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#62988}
-
- 29 Jul, 2019 3 commits
-
-
Clemens Hammacher authored
This is a reland of 658ff200 Original change's description: > [utils] Make BitField final > > We have hundreds of classes that derive from {BitField} without adding > any functionality. This CL switches all such occurrences to 'using' > declarations instead. > > Before: > class MyBitField : public BitField<int, 6, 4, MyEnum> {}; > After: > using MyBitField = BitField<int, 6, 4, MyEnum>; > > This might reduce compilation time by reducing the number of existing > classes. > > The old pattern is forbidden now by making {BitField} final. > > R=yangguo@chromium.org > > Bug: v8:9396, v8:7629 > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62956} Bug: v8:9396, v8:7629 Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62959}
-
Clemens Hammacher authored
This reverts commit 658ff200. Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826 Original change's description: > [utils] Make BitField final > > We have hundreds of classes that derive from {BitField} without adding > any functionality. This CL switches all such occurrences to 'using' > declarations instead. > > Before: > class MyBitField : public BitField<int, 6, 4, MyEnum> {}; > After: > using MyBitField = BitField<int, 6, 4, MyEnum>; > > This might reduce compilation time by reducing the number of existing > classes. > > The old pattern is forbidden now by making {BitField} final. > > R=yangguo@chromium.org > > Bug: v8:9396, v8:7629 > Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62956} TBR=yangguo@chromium.org,clemensh@chromium.org Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9396, v8:7629 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62958}
-
Clemens Hammacher authored
We have hundreds of classes that derive from {BitField} without adding any functionality. This CL switches all such occurrences to 'using' declarations instead. Before: class MyBitField : public BitField<int, 6, 4, MyEnum> {}; After: using MyBitField = BitField<int, 6, 4, MyEnum>; This might reduce compilation time by reducing the number of existing classes. The old pattern is forbidden now by making {BitField} final. R=yangguo@chromium.org Bug: v8:9396, v8:7629 Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62956}
-
- 01 Jul, 2019 1 commit
-
-
Leszek Swirski authored
The previous fix for this bug (crrev.com/c/1678365) pessimistically would mark all shadowed variables as maybe_assigned. Unfortunately, this doesn't work across a parse/preparse boundary, where the shadowing variable is found via Scope::AnalyzePartially while the shadowed variable is outside of the preparser entry point. In those cases, the referencing proxy is copied to the outer scope, in which case the dynamicness of the original lookup is lost and the maybe_assigned pessimisation no longer applies. This means that maybe_assigned status of a variable is dependent on which function is being parsed. In particular, it can cause bytecode to change on recompilation, causing issues for lazy source positions. This patch allows SetMaybeAssigned to walk its shadowed variables, and recursively set them to maybe_assigned too. Checking for maybe_assigned changing prevents this recursion from having a quadratic performance failure mode. Bug: v8:8510 Bug: v8:9394 Change-Id: Id19fe1fad5ec8f0f9aa03b00eb24497f88f71216 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1677265 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#62458}
-
- 18 Jun, 2019 1 commit
-
-
Joyee Cheung authored
This patch adds a new assign type `PRIVATE_METHOD`. We now use this for private method references in the form `obj.#key` when `#key` resolves to a private method. To obtain the type of the key variables after scope analysis, this patch add a bit to Variable to recognize private method variables whose load requires a brand check. Also renamed `PropertyExpressionWithPrivateFieldKey` in ExpressionType to `PrivateReference` and added `PRIVATE_CALL` to `CallType` - we'll use the new types later when we implement private methods, which require special brand checking semantics to load methods directly from the context instead of from the object in order to save memory. Bug: v8:8330 Change-Id: Idc1dcd4d514c1b3f8a31c99e49e34249449f0677 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1642772 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#62255}
-
- 27 May, 2019 1 commit
-
-
Clemens Hammacher authored
This replaces all typedefs that define types and not functions by the equivalent "using" declaration. This was done mostly automatically using this command: ag -l '\btypedef\b' src test | xargs -L1 \ perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg' Patchset 2 then adds some manual changes for typedefs for pointer types, where the regular expression did not match. R=mstarzinger@chromium.org TBR=yangguo@chromium.org, jarin@chromium.org Bug: v8:9183 Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61849}
-
- 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}
-
- 26 Feb, 2019 1 commit
-
-
Sigurd Schneider authored
Change-Id: I4bd02bdb68727b6242b0fe4b81fd522813b13f39 Bug: v8:8834 Reviewed-on: https://chromium-review.googlesource.com/c/1488755Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59875}
-
- 06 Feb, 2019 1 commit
-
-
Toon Verwaest authored
"this" is a very common expression. By using a single ThisExpression object we can both avoid allocating many unnecessary VariableProxies and specialize the resolution of this since we know where it's declared up-front. This also avoids having to special-case "this" reference handling in the paths that would behave differently for "this" than for regular references; e.g., with-scopes. The tricky pieces are due to DebugEvaluate and this/super() used as default parameters of arrow functions. In the former case we replace the WITH_SCOPE with FUNCTION_SCOPE so that we make sure that "this" is intercepted, and still rely on regular dynamic variable lookup. Arrow functions are dealt with by marking "this" use in ArrowHeadParsingScopes. If the parenthesized expression ends up being an arrow function, we force context allocate on the outer scope (and mark "has_this_reference" on the FUNCTION_SCOPE so DebugEvaluate in the arrow function can expose "this"). The CL also removes the now unused ThisFunction AST node. Change-Id: I0ca38ab92ff58c2f731e07db2fbe91df901681ef Reviewed-on: https://chromium-review.googlesource.com/c/1448313Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59393}
-
- 25 Jan, 2019 1 commit
-
-
Toon Verwaest authored
Change-Id: I83dc3bed644361be1b94063daefd890b10ba50cd Reviewed-on: https://chromium-review.googlesource.com/c/1433772 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#59095}
-
- 21 Jan, 2019 2 commits
-
-
Toon Verwaest authored
Walk the VariableMap instead of the ast. Change-Id: I03ee9145230bcbfe04c5e31dc8d8b3a98a00a4be Reviewed-on: https://chromium-review.googlesource.com/c/1424865 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58968}
-
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}
-
- 10 Jan, 2019 1 commit
-
-
Toon Verwaest authored
This will make it easier to separate out parameter declaration from other other parameter scope information tracking. Change-Id: I8712dd7fc589c84bc1e1a1eab9038af6047b21cd Reviewed-on: https://chromium-review.googlesource.com/c/1403118 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#58698}
-
- 02 Nov, 2018 1 commit
-
-
Toon Verwaest authored
Restructure the code a little, and change how we detect sloppy block function redeclaration so we don't dereference a possibly nullptr function. Bug: chromium:900786 Change-Id: Ief124fe767603ca36f4dc8865c4aeb3e0635b4cf Reviewed-on: https://chromium-review.googlesource.com/c/1314331Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57206}
-
- 27 Sep, 2018 1 commit
-
-
Florian Sattler authored
Change-Id: I49a4e9740f6a3715ca5cdafd121b3b99fed8dc6b Reviewed-on: https://chromium-review.googlesource.com/1245428Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Florian Sattler <sattlerf@google.com> Cr-Commit-Position: refs/heads/master@{#56267}
-
- 03 Sep, 2018 1 commit
-
-
Florian Sattler authored
PreParser types, e.g., PreParserExpression, PreParserList, PreParserFormalParameter. This also enhances ThreadedLists to be used on the same class more than once. Bug: v8:7926 Change-Id: Ied204120e5d12ab1f1c4192f6b3c05971a12683b Reviewed-on: https://chromium-review.googlesource.com/1199262 Commit-Queue: Florian Sattler <sattlerf@google.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#55584}
-
- 29 May, 2018 1 commit
-
-
Sebastien Marchand authored
see crbug.com/841460 , we recently hit some build issues when using Goma + jumbo builds because of a conflict on the definition of CONST, v8 defines it in globals.h and including windows.h also defines it. It should be possible to fix this by adding a bunch of #undef CONST but it seems a little bit hacky and might not always work (this could only fix the problem temporary if the jumbo merge limit changes and cause some include files to get included in a different order). Renaming the v8 definition of CONST to kConst, this follows the style guide guidelines: "there is no reason to change old code to use constant-style names, unless the old names are actually causing a compile-time problem" (https://google.github.io/styleguide/cppguide.html#Enumerator_Names) I also had to turn the PropertyConstness enum into an enum class to avoid some conflicts (both PropertyConstness and VariableMode define kConst). Bug: chromium:841460 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I2b70b9095374e88a5ae364cc557b39f20a3ab60f Reviewed-on: https://chromium-review.googlesource.com/1064197Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sébastien Marchand <sebmarchand@chromium.org> Cr-Commit-Position: refs/heads/master@{#53413}
-
- 13 Oct, 2017 1 commit
-
-
Mathias Bynens authored
New code should use nullptr instead of NULL. This patch updates existing use of NULL to nullptr where applicable, making the code base more consistent. BUG=v8:6928,v8:6921 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I4687f5b96fcfd88b41fa970a2b937b4f6538777c Reviewed-on: https://chromium-review.googlesource.com/718338 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#48557}
-
- 26 Jun, 2017 1 commit
-
-
hans authored
This is towards closing the perf gap between the MSVC build (which uses link- time optimization) and Clang (where LTO isn't ready on Windows yet). We did a study (see bug) to see which non-inlined functions are hit a lot during render start-up, and which would be inlined during LTO. This should benefit performance in all builds which currently don't use LTO (Android, Linux, Mac) as well as the Win/Clang build. The binary size of chrome_child.dll increases by 2KB with this. BUG=chromium:728324 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng Review-Url: https://codereview.chromium.org/2950993002 Cr-Commit-Position: refs/heads/master@{#46229}
-
- 25 Jun, 2017 1 commit
-
-
machenbach authored
Revert of Make some functions that are hit during renderer startup available for inlining (patchset #3 id:40001 of https://codereview.chromium.org/2950993002/ ) Reason for revert: Blocks roll: https://codereview.chromium.org/2954833002/ E.g.: https://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_compile_dbg_ng/builds/449680 https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_compile_dbg_ng/builds/324953 Please include those chromium trybots on reland. Maybe missing symbol export? Original issue's description: > Make some functions that are hit during renderer startup available for inlining > > This is towards closing the perf gap between the MSVC build (which uses link- > time optimization) and Clang (where LTO isn't ready on Windows yet). We did > a study (see bug) to see which non-inlined functions are hit a lot during render > start-up, and which would be inlined during LTO. This should benefit performance > in all builds which currently don't use LTO (Android, Linux, Mac) as well as > the Win/Clang build. > > The binary size of chrome_child.dll increases by 2KB with this. > > BUG=chromium:728324 > > Review-Url: https://codereview.chromium.org/2950993002 > Cr-Commit-Position: refs/heads/master@{#46191} > Committed: https://chromium.googlesource.com/v8/v8/+/d00d52be1fce9c1bf5558c8b26bf984efd09e65b TBR=jochen@chromium.org,mstarzinger@chromium.org,rmcilroy@chromium.org,vogelheim@chromium.org,marja@chromium.org,mlippautz@chromium.org,thakis@chromium.org,hans@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=chromium:728324 NOTRY=true NOPRESUBMIT=true Review-Url: https://codereview.chromium.org/2955793002 Cr-Commit-Position: refs/heads/master@{#46195}
-
- 23 Jun, 2017 1 commit
-
-
hans authored
This is towards closing the perf gap between the MSVC build (which uses link- time optimization) and Clang (where LTO isn't ready on Windows yet). We did a study (see bug) to see which non-inlined functions are hit a lot during render start-up, and which would be inlined during LTO. This should benefit performance in all builds which currently don't use LTO (Android, Linux, Mac) as well as the Win/Clang build. The binary size of chrome_child.dll increases by 2KB with this. BUG=chromium:728324 Review-Url: https://codereview.chromium.org/2950993002 Cr-Commit-Position: refs/heads/master@{#46191}
-
- 22 Jun, 2017 1 commit
-
-
Marja Hölttä authored
let f = function g() { ... } declares "g" inside the function. This CL makes the preparser declare it too, and saves + restores the scope data for it. BUG=v8:5516 Change-Id: Id4c64f446d30f5252038cfb0f0f473b85ba24a9b Reviewed-on: https://chromium-review.googlesource.com/544816 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org> Cr-Commit-Position: refs/heads/master@{#46133}
-
- 08 May, 2017 1 commit
-
-
Adam Klein authored
This patch expands scope analysis to skip hole initialization when it can be determined statically that no hole checks will be generated at runtime. Two conditions must be met to safely eliminate hole initialization: - There must not exist a VariableProxy referencing this Variable whose HoleCheckMode is kRequired - The Variable must be stack allocated; any other allocation implies that it may be accessed from not-yet-analyzed scopes (other modules, inner functions, or eval code) and that code may require hole checks. The new logic required removing debug code in full-codegen which is now incorrect in some cases. Also fixed Variable's bitfield helpers to take no more space than needed. Bug: chromium:651637 Change-Id: Ie5ac326af4e05b7a5c3c37cd4d0afba6a51a504d Reviewed-on: https://chromium-review.googlesource.com/494006 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#45170}
-
- 30 Mar, 2017 1 commit
-
-
Franziska Hinkelmann authored
The parameter indices are shifted by 1 in BytecodeArrayBuilder because the receiver is variable at index 0 and not -1. Split BytecodeArrayBuilder::Parameter(index) method into Receiver() (same as Parameter(-1)) and Parameter(index). This way we avoid confusing (index+1) counting in BytecodeGenerator(). BUG= Change-Id: Id87ec7c708cecfc3108011994f3177f483772bcc Reviewed-on: https://chromium-review.googlesource.com/461904Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#44262}
-
- 04 Nov, 2016 2 commits
-
-
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}
-
neis authored
Instead of having a MODULE variable's index be 0 or 1, let it be the index of its cell. In this CL, we assign the indices but we continue to only use them to distinguish imports from exports. Actually using them to directly access the cells will be done in a later CL. R=adamk@chromium.org BUG=v8:1569 Review-Url: https://codereview.chromium.org/2460233003 Cr-Commit-Position: refs/heads/master@{#40752}
-