- 13 May, 2022 1 commit
-
-
Clemens Backes authored
Now that we require C++17 support, we can just use the standard static_assert without message, instead of our STATIC_ASSERT macro. R=leszeks@chromium.org Bug: v8:12425 Change-Id: I1d4e39c310b533bcd3a4af33d027827e6c083afe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647353Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#80524}
-
- 10 May, 2022 1 commit
-
-
Shu-yu Guo authored
Private brand checks have shipped since M91. Bug: v8:11374 Change-Id: Ifd2f8e9904cdb25b45b2e4019da13b3cfc9efdc5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3622266Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Auto-Submit: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#80455}
-
- 03 May, 2022 1 commit
-
-
Camillo Bruni authored
To be consistent with the all the other tiers and avoid confusion, we rename --opt to ---turbofan, and --always-opt to --always-turbofan. Change-Id: Ie23dc8282b3fb4cf2fbf73b6c3d5264de5d09718 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610431Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#80336}
-
- 25 Apr, 2022 1 commit
-
-
jameslahm authored
This is a reland of commit 62632c08. Reason for previous revert: Performance regressions crbug.com/1315724. The reland only optimizes strict equal boolean literal like "a===true" or "a===false", and we generate TestReferenceEqual rather than TestStrictEqual for the comparasion. And also add typed optimization for ReferenceEqual when all inputs are boolean with boolean constant. Original change's description: > [interpreter] Optimize strict equal boolean > > For strict equal boolean literal like "a===true" > or "a===false", we could generate TestReferenceEqual > rather than TestStrictEqual. And in `execution_result()->IsTest()` > case, we could directly emit JumpIfTrue/JumpIfFalse. > > E.g. > ``` > a === true > ``` > Generated Bytecode From: > ``` > LdaGlobal > Star1 > LdaTrue > TestEqualStrict > ``` > To: > ``` > LdaGlobal > Star1 > LdaTrue > TestReferenceEqual > ``` > > E.g. > ``` > if (a === true) > ``` > Generated Bytecode From: > ``` > LdaGlobal > Star1 > LdaTrue > TestEqualStrict > JumpIfFalse > ``` > To > ``` > LdaGlobal > JumpIfTrue > Jump > ``` > > > Bug: v8:6403 > Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: 王澳 <wangao.james@bytedance.com> > Cr-Commit-Position: refs/heads/main@{#79935} Bug: v8:6403 Change-Id: I2ae3ab57dce85313af200fa522e3632af5c3a554 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3592039Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#80141}
-
- 22 Apr, 2022 1 commit
-
-
jameslahm authored
This CL extends GetIterator to check whether the result of calling @@iterator is JSReceiver and throw SymbolIteratorInvalid if it's not JSReceiver. GetIterator bytecode involves 3 steps now: - method = GetMethod(obj, @@iterator) - iterator = Call(method, obj) - if(!IsJSReceiver(iterator)) throw SymbolIteratorInvalid [Added] New Builtin: CallIteratorWithFeedbackLazyDeoptContinuation, which is used when lazy deopt is triggered by call @@iterator. Related spec: https://tc39.es/ecma262/#sec-getiterator. Related doc: https://docs.google.com/document/d/1s67HC2f-4zxA_s1Bmm7dfwMFv_KDUfMiWIKkNSeQNKw/edit#heading=h.kdzv8mq4g4ks. Bug: v8:9489 Change-Id: I17952c0f3e24e1e600ee1348809fb188c2c70f8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563447Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: 王澳 <wangao.james@bytedance.com> Cr-Commit-Position: refs/heads/main@{#80112}
-
- 20 Apr, 2022 1 commit
-
-
Jakob Gruber authored
.. which points back at the corresponding feedback vector slot for each JumpLoop bytecode. Bug: v8:12161 Change-Id: I95f4d013544a69e088314655af7eb1dc504a8657 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596166Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#80048}
-
- 19 Apr, 2022 1 commit
-
-
Jakob Linke authored
This reverts commit 62632c08. Reason for revert: Performance regressions crbug.com/1315724 Original change's description: > [interpreter] Optimize strict equal boolean > > For strict equal boolean literal like "a===true" > or "a===false", we could generate TestReferenceEqual > rather than TestStrictEqual. And in `execution_result()->IsTest()` > case, we could directly emit JumpIfTrue/JumpIfFalse. > > E.g. > ``` > a === true > ``` > Generated Bytecode From: > ``` > LdaGlobal > Star1 > LdaTrue > TestEqualStrict > ``` > To: > ``` > LdaGlobal > Star1 > LdaTrue > TestReferenceEqual > ``` > > E.g. > ``` > if (a === true) > ``` > Generated Bytecode From: > ``` > LdaGlobal > Star1 > LdaTrue > TestEqualStrict > JumpIfFalse > ``` > To > ``` > LdaGlobal > JumpIfTrue > Jump > ``` > > > Bug: v8:6403 > Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: 王澳 <wangao.james@bytedance.com> > Cr-Commit-Position: refs/heads/main@{#79935} Bug: v8:6403, chromium:1315724 Change-Id: I65c520590093724e838f738c795d229687efb9de Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3592752Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#80010}
-
- 12 Apr, 2022 1 commit
-
-
jameslahm authored
For strict equal boolean literal like "a===true" or "a===false", we could generate TestReferenceEqual rather than TestStrictEqual. And in `execution_result()->IsTest()` case, we could directly emit JumpIfTrue/JumpIfFalse. E.g. ``` a === true ``` Generated Bytecode From: ``` LdaGlobal Star1 LdaTrue TestEqualStrict ``` To: ``` LdaGlobal Star1 LdaTrue TestReferenceEqual ``` E.g. ``` if (a === true) ``` Generated Bytecode From: ``` LdaGlobal Star1 LdaTrue TestEqualStrict JumpIfFalse ``` To ``` LdaGlobal JumpIfTrue Jump ``` Bug: v8:6403 Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: 王澳 <wangao.james@bytedance.com> Cr-Commit-Position: refs/heads/main@{#79935}
-
- 23 Mar, 2022 1 commit
-
-
Joyee Cheung authored
Since assignments to read-only private references can be skipped due to short-circuiting in logical assignments, we should not eagerly emit the error of invalid writes, and should instead load the values as usual, only emitting an error when the assignment happens, which can be handled by BytecodeGenerator::BuildAssignment(). Bug: v8:12680, v8:8330, v8:10372 Change-Id: Ia5fea9090bc48b0af8a9c8d6f95174f7aa2d86f8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3509298Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#79583}
-
- 10 Mar, 2022 1 commit
-
-
jameslahm authored
when BuildCreateArrayLiteral In spread calls, create array literal boilerplates for BuildCreateArrayLiteral rather than emit array literals without any boilerplates Bug: v8:11582 Change-Id: Ia0538bd043eab040c3059440e982c7f0037d1a3f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3507126Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79447}
-
- 08 Mar, 2022 1 commit
-
-
Joyee Cheung authored
For background and reasoning, see https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit This is the first step towards pulling the DefineNamedOwn operation out of StoreIC. Summary of the renamed identifiers: Bytecodes: - StaNamedProperty -> SetNamedProperty: calls StoreIC and emitted for normal named property sets like obj.x = 1. - StaNamedOwnProperty -> DefineNamedOwnProperty: calls DefineNamedOwnIC (previously StoreOwnIC), and emitted for initialization of named properties in object literals and named public class fields. - StaKeyedProperty -> SetKeyedProperty: calls KeyedStoreIC and emitted for keyed property sets like obj[x] = 1. - StaKeyedPropertyAsDefine -> DefineKeyedOwnProperty: calls DefineKeyedOwnIC (previously KeyedDefineOwnIC) and emitted for initialization of private class fields and computed public class fields. - StaDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral: calls DefineKeyedOwnPropertyInLiteral runtime function (previously DefineDataPropertyInLiteral) and emitted for initialization of keyed properties in object literals and static class initializers. (note that previously the StoreDataPropertyInLiteral runtime function name was taken by object spreads and array literal creation instead) - LdaKeyedProperty -> GetKeyedProperty, LdaNamedProperty -> GetNamedProperty, LdaNamedPropertyFromSuper -> GetNamedPropertyFromSuper: we drop the Sta prefix for the property store operations since the accumulator use is implicit and to make the wording more natural, for symmetry the Lda prefix for the property load operations is also dropped. opcodes: - (JS)StoreNamed -> (JS)SetNamedProperty: implements set semantics for named properties, compiled from SetNamedProperty (previously StaNamedProperty) and lowers to StoreIC or Runtime::kSetNamedProperty - (JS)StoreNamedOwn -> (JS)DefineNamedOwnProperty: implements define semantics for initializing named own properties in object literal and public class fields, compiled from DefineNamedOwnProperty (previously StaNamedOwnProperty) and lowers to DefineNamedOwnIC (previously StoreOwnIC) - (JS)StoreProperty -> (JS)SetKeyedProperty: implements set semantics for keyed properties, only compiled from SetKeyedProperty(previously StaKeyedProperty) and lowers to KeyedStoreIC - (JS)DefineProperty -> (JS)DefineKeyedOwnProperty: implements define semantics for initialization of private class fields and computed public class fields, compiled from DefineKeyedOwnProperty (previously StaKeyedPropertyAsDefine) and calls DefineKeyedOwnIC (previously KeyedDefineOwnIC). - (JS)StoreDataPropertyInLiteral -> (JS)DefineKeyedOwnPropertyInLiteral: implements define semantics for initialization of keyed properties in object literals and static class initializers, compiled from DefineKeyedOwnPropertyInLiteral (previously StaDataPropertyInLiteral) and calls the DefineKeyedOwnPropertyInLiteral runtime function (previously DefineDataPropertyInLiteral). Runtime: - DefineDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral: following the bytecode/opcodes change, this is used by DefineKeyedOwnPropertyInLiteral (previously StaDataPropertyInLiteral) for object and class literal initialization. - StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral_Simple: it's just a simplified version of DefineDataPropertyInLiteral that does not update feedback or perform function name configuration. This is used by object spread and array literal creation. Since we are renaming DefineDataPropertyInLiteral to DefineKeyedOwnPropertyInLiteral, rename this simplified version with a `_Simple` suffix. We can consider merging it into DefineKeyedOwnPropertyInLiteral in the future. See https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit?disco=AAAAQQIz6mU - Other changes following the bytecode/IR changes IC: - StoreOwn -> DefineNamedOwn: used for initialization of named properties in object literals and named public class fields. - StoreOwnIC -> DefineNamedOwnIC - StoreMode::kStoreOwn -> StoreMode::kDefineNamedOwn - StoreICMode::kStoreOwn -> StoreICMode::kDefineNamedOwn - IsStoreOwn() -> IsDefineNamedOwn() - DefineOwn -> DefineKeyedOwn: IsDefineOwnIC() was already just IsDefineKeyedOwnIC(), and IsAnyDefineOwn() includes both named and keyed defines so we don't need an extra generic predicate. - StoreMode::kDefineOwn -> StoreMode::kDefineKeyedOwn - StoreICMode::kDefineOwn -> StoreICMode::kDefineKeyedOwn - IsDefineOwn() -> IsDefineKeyedOwn() - IsDefineOwnIC() -> IsDefineKeyedOwnIC() - Removing IsKeyedDefineOwnIC() as its now a duplicate of IsDefineKeyedOwnIC() - KeyedDefineOwnIC -> DefineKeyedOwnIC, KeyedDefineOwnGenericGenerator() -> DefineKeyedOwnGenericGenerator: make the ordering of terms more consistent - IsAnyStoreOwn() -> IsAnyDefineOwn(): this includes the renamed and DefineNamedOwn and DefineKeyedOwn. Also is_any_store_own() is removed since it's just a duplicate of this. - IsKeyedStoreOwn() -> IsDefineNamedOwn(): it's unclear where the "keyed" part came from, but it's only used when DefineNamedOwnIC (previously StoreOwnIC) reuses KeyedStoreIC, so rename it accordingly Interpreter & compiler: - BytecodeArrayBuilder: following bytecode changes - StoreNamedProperty -> SetNamedProperty - StoreNamedOwnProperty -> DefineNamedOwnProperty - StoreKeyedProperty -> SetKeyedProperty - DefineKeyedProperty -> DefineKeyedOwnProperty - StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral - FeedbackSlotKind: - kDefineOwnKeyed -> kDefineKeyedOwn: make the ordering of terms more consistent - kStoreOwnNamed -> kDefineNamedOwn: following the IC change - kStoreNamed{Sloppy|Strict} -> kSetNamed{Sloppy|Strict}: only used in StoreIC for set semantics - kStoreKeyed{Sloppy|Strict} -> kSetKeyed{Sloppy|Strict}: only used in KeyedStoreIC for set semantics - kStoreDataPropertyInLiteral -> kDefineKeyedOwnPropertyInLiteral: following the IC change - BytecodeGraphBuilder - StoreMode::kNormal, kOwn -> NamedStoreMode::kSet, kDefineOwn: this is only used by BytecodeGraphBuilder::BuildNamedStore() to tell the difference between SetNamedProperty and DefineNamedOwnProperty operations. Not changed: - StoreIC and KeyedStoreIC currently contain mixed logic for both Set and Define operations, and the paths are controlled by feedback. The plan is to refactor the hierarchy like this: ``` - StoreIC - DefineNamedOwnIC - SetNamedIC (there could also be a NamedStoreIC if that's helpful) - KeyedStoreIC - SetKeyedIC - DefineKeyedOwnIC - DefineKeyedOwnICLiteral (could be merged into DefineKeyedOwnIC) - StoreInArrayLiteralIC - ... ``` StoreIC and KeyedStoreIC would then contain helpers shared by their subclasses, therefore it still makes sense to keep the word "Store" in their names since they would be generic base classes for both set and define operations. - The Lda and Sta prefixes of bytecodes not involving object properties (e.g. Ldar, Star, LdaZero) are kept, since this patch focuses on property operations, and distinction between Set and Define might be less relevant or nonexistent for bytecodes not involving object properties. We could consider rename some of them in future patches if that's helpful though. Bug: v8:12548 Change-Id: Ia36997b02f59a87da3247f20e0560a7eb13077f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3481475Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#79409}
-
- 03 Mar, 2022 1 commit
-
-
jameslahm authored
- add CopyDataPropertiesWithExcludedProperties intrinsic - add CopyDataPropertiesWithExcludedProperties_Baseline intrinsic Bug: v8:11614 Change-Id: Ie6a3db4c9edda40ecf84b8d1107e70fd7ff0d5fb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3470349Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79342}
-
- 15 Feb, 2022 1 commit
-
-
jameslahm authored
according https://tc39.es/ecma262/#sec-runtime-semantics-iteratordestructuringassignmentevaluation, when desturcturing assignment with elision, iteratorValue should not be called, thus the returned object's "value" property should not be read during the assignment. Bug: v8:12595 Change-Id: Id4b2c236c30486397683b4ccd4d156b718e12df3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3459922Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79093}
-
- 10 Feb, 2022 1 commit
-
-
Joyee Cheung authored
Handle the case of nested super() by checking if the class scope contains a private brand. In this case the ContextScope chain is different from the actual context chain so this added back the AddPrivateBrand() runtime function but with the additional step of walking the context chain to get the correct class context that will be stored as the value of the brand property for the debugger. Bug: v8:12354 Change-Id: Ieeb9b9d6372bfbb1a39c4c2dc9e9848e9109f02a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275137Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#79032}
-
- 02 Feb, 2022 1 commit
-
-
Shu-yu Guo authored
Bug: v8:12563 Change-Id: I564c973d5d03c198bffc8edba8d9a3b7ec66c8e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3423581 Auto-Submit: Shu-yu Guo <syg@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78897}
-
- 24 Jan, 2022 1 commit
-
-
Joyee Cheung authored
This is a reland of 91f08378 When the class scope does not need a context, the deserialized outer scope of the initializer scope would not be the class scope, and we should not and do not need to use it to fix up the allocation information of the context-allocated variables. The original patch did not consider this case and resulted in a regression when we tried to reparse the initializer function to look for destructuring assignment errors. This fixes the regression by not deserializing the class scope that's going to be reparsed, and using the positions of the scopes to tell whether the scope info matches the reparsed scope and can be used to fix up the allocation info. Original change's description: > [class] implement reparsing of class instance member initializers > > Previously, since the source code for the synthetic class instance > member initializer function was recorded as the span from the first > initializer to the last initializer, there was no way to reparse the > class and recompile the initializer function. It was working for > most use cases because the code for the initializer function was > generated eagarly and it was usually alive as long as the class was > alive, so the initializer wouldn't normally be lazily parsed. This > didn't work, however, when the class was snapshotted with > v8::SnapshotCreator::FunctionCodeHandling::kClear, > becuase then we needed to recompile the initializer when the class > was instantiated. This patch implements the reparsing so that > these classes can work with FunctionCodeHandling::kClear. > > This patch refactors ParserBase::ParseClassLiteral() so that we can > reuse it for both parsing the class body normally and reparsing it > to collect initializers. When reparsing the synthetic initializer > function, we rewind the scanner to the beginning of the class, and > parse the class body to collect the initializers. During the > reparsing, field initializers are parsed with the full parser while > methods of the class are pre-parsed. > > A few notable changes: > > - Extended the source range of the initializer function to cover the > entire class so that we can rewind the scanner to parse the class > body to collect initializers (previously, it starts from the first > field initializer and ends at the last initializer). This resulted > some expectation changes in the debugger tests, though the > initializers remain debuggable. > - A temporary ClassScope is created during reparsing. After the class > is reparsed, we use the information from the ScopeInfo to update > the allocated indices of the variables in the ClassScope. > > Bug: v8:10704 > Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Joyee Cheung <joyee@igalia.com> > Cr-Commit-Position: refs/heads/main@{#78299} Bug: chromium:1278086, chromium:1278085, v8:10704 Change-Id: Iea4f1f6dc398846cbe322adc16f6fffd6d2dfdf3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325912Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#78745}
-
- 13 Jan, 2022 1 commit
-
-
Benedikt Meurer authored
This unifies and simplifies the way we instrument async functions for the purpose of async stack traces and async stepping. It does so while retaining the observable behavior on the inspector level (for now). Previously we'd mark the implicit promise of the async function object with the async task ID, and whenever we awaited, we'd copy the async task ID to the throwaway promise that is created by the `await`. This however made things unnecessarily interesting in the following regards: 1. We'd see `DebugDidHandle` and `DebugWillHandle` events after the `AsyncFunctionFinished` events, coming from the throwaway promises, while the implicit promise is "done". This is especially confusing with rejection propagation and requires very complex stepping logic for async functions (after this CL it'll be possible to unify and simplify the stepping logic). 2. We have to thread through the "can suspend" information from the Parser all the way through AsyncFunctionReject/AsyncFunctionResolve to the async function instrumentation to decide whether to cancel the pending task when the async function finishes. This CL changes the instrumentation to only happen (non recurringly) for the throwaway promises allocated upon `await`. This solves both problems mentioned above, and works because upon the first `await` the stack captured for the throwaway promise will include the synchronous part as expected, while upon later `await`s the synchronous part will be empty and the asynchronous part will be the stack captured for the previous throwaway promise (and the V8Debugger automatically short circuits stacks with empty synchronous part). Bug: chromium:1280519, chromium:1277451, chromium:1246867 Change-Id: Id604dabc19ea133ea2e9dd63181b1fc33ccb5eda Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383775Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78599}
-
- 09 Dec, 2021 1 commit
-
-
Joyee Cheung authored
This reverts commit 91f08378. Reason for revert: It's a fairly big change, and the clusterfuzz found some bugs. Will reland with the fix after M98 branch point. Original change's description: > [class] implement reparsing of class instance member initializers > > Previously, since the source code for the synthetic class instance > member initializer function was recorded as the span from the first > initializer to the last initializer, there was no way to reparse the > class and recompile the initializer function. It was working for > most use cases because the code for the initializer function was > generated eagarly and it was usually alive as long as the class was > alive, so the initializer wouldn't normally be lazily parsed. This > didn't work, however, when the class was snapshotted with > v8::SnapshotCreator::FunctionCodeHandling::kClear, > becuase then we needed to recompile the initializer when the class > was instantiated. This patch implements the reparsing so that > these classes can work with FunctionCodeHandling::kClear. > > This patch refactors ParserBase::ParseClassLiteral() so that we can > reuse it for both parsing the class body normally and reparsing it > to collect initializers. When reparsing the synthetic initializer > function, we rewind the scanner to the beginning of the class, and > parse the class body to collect the initializers. During the > reparsing, field initializers are parsed with the full parser while > methods of the class are pre-parsed. > > A few notable changes: > > - Extended the source range of the initializer function to cover the > entire class so that we can rewind the scanner to parse the class > body to collect initializers (previously, it starts from the first > field initializer and ends at the last initializer). This resulted > some expectation changes in the debugger tests, though the > initializers remain debuggable. > - A temporary ClassScope is created during reparsing. After the class > is reparsed, we use the information from the ScopeInfo to update > the allocated indices of the variables in the ClassScope. > > Bug: v8:10704 > Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Joyee Cheung <joyee@igalia.com> > Cr-Commit-Position: refs/heads/main@{#78299} Bug: v8:10704 Change-Id: I039cb728ebf0ada438a8f26c7d2c2547dbe3bf2d No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325328 Auto-Submit: Joyee Cheung <joyee@igalia.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78315}
-
- 08 Dec, 2021 2 commits
-
-
Joyee Cheung authored
Previously, since the source code for the synthetic class instance member initializer function was recorded as the span from the first initializer to the last initializer, there was no way to reparse the class and recompile the initializer function. It was working for most use cases because the code for the initializer function was generated eagarly and it was usually alive as long as the class was alive, so the initializer wouldn't normally be lazily parsed. This didn't work, however, when the class was snapshotted with v8::SnapshotCreator::FunctionCodeHandling::kClear, becuase then we needed to recompile the initializer when the class was instantiated. This patch implements the reparsing so that these classes can work with FunctionCodeHandling::kClear. This patch refactors ParserBase::ParseClassLiteral() so that we can reuse it for both parsing the class body normally and reparsing it to collect initializers. When reparsing the synthetic initializer function, we rewind the scanner to the beginning of the class, and parse the class body to collect the initializers. During the reparsing, field initializers are parsed with the full parser while methods of the class are pre-parsed. A few notable changes: - Extended the source range of the initializer function to cover the entire class so that we can rewind the scanner to parse the class body to collect initializers (previously, it starts from the first field initializer and ends at the last initializer). This resulted some expectation changes in the debugger tests, though the initializers remain debuggable. - A temporary ClassScope is created during reparsing. After the class is reparsed, we use the information from the ScopeInfo to update the allocated indices of the variables in the ClassScope. Bug: v8:10704 Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#78299}
-
Leszek Swirski authored
Introduce a ReusableUnoptimizedCompileState class, passed to ParseInfo, which stores a couple of pointers and most importantly the Zone and AstValueFactory of the parse. This allows the Zone and AstValueFactory to be reused across multiple parses, rather than re-initialising per-Parse. With this, we can amend the LazyCompileDispatcher to initialise one LocalIsolate, Zone and AstValueFactory per background thread loop, rather than one per compile task, which allows us to reduce per-task costs and re-use the AstValueFactory's string table and previous String internalizations. Change-Id: Ia0e29c4e31fbe29af57674ebb10916865d38b2ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313106Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78289}
-
- 03 Dec, 2021 1 commit
-
-
Leszek Swirski authored
Rather than creating a ParseInfo when creating a BackgroundCompileTask (and passing ownership across to the BG thread which deallocates it), create one when running it. This allows the ParseInfo Zone to be both allocated and deallocated on the same thread, which will improve its allocator friendliness. As a side-effect, we now use the on-heap PreparseData from the SharedFunctionInfo, rather than cloning the in-Zone PreparseData. This means that we don't have to copy the PreparseData across Zones, but we do need to Unpark the LocalHeap when accessing preparse data. Change-Id: I16d976c1ad54c1090180f2936f40a23a6dbb5904 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312483Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78228}
-
- 01 Dec, 2021 2 commits
-
-
Leszek Swirski authored
Add suppose for compiling non-eager, non-top-level inner functions in parallel, using the compiler dispatcher. This behaviour can be enabled with --parallel-compile-tasks-for-lazy. There are a couple of consequences: * To support this we need support for off-thread ScopeInfo deserialization, so this adds that too. * The previous --parallel-compile-tasks flag is renamed to the more descriptive --parallel-compile-tasks-for-eager-toplevel. * Both parallel-compile-tasks flags are moved onto UnoptimizedCompileFlags so that they can be enabled/disabled on a per-compile basis (e.g. enabled for streaming, disabled for re-parsing). * asm.js compilations can now happen without an active Context (in the compiler dispatcher's idle finalization) so we can't get a ContextId for metric reporting; we'd need to somehow fix this if we wanted asm.js UKM but for now it's probably fine. * Took the opportunity to clean up some of the "can preparse" logic in the parser. Change-Id: I20b1ec6a6bacfe268808edc8d812b92370c5840d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281924 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org> Cr-Commit-Position: refs/heads/main@{#78183}
-
Leszek Swirski authored
Try blocks (whether catch or finally) will unconditionally create handler tables and start a new basic block for the exception handler. This can accidentally resurrect a dead block when the entire try block is dead (and hence can never enter the exception handler in the first place). Add a deadness check to BuildTryCatch/Finally to fix this. Bug: chromium:1273677 Change-Id: Icda9deb1459e47de5cb83e7b636299e24c3ebe77 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306555 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78179}
-
- 19 Nov, 2021 1 commit
-
-
Ray Wang authored
Bug: v8:12389 Change-Id: I53c728ab0c8ba38c7dd96c7e1089f771ba44b9f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3289227Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#77995}
-
- 17 Nov, 2021 1 commit
-
-
Kim-Anh Tran authored
Move the source code position for classes to the point where the block context has already been created. Previously, there would be a mismatch between the context and the scope when using the ScopeIterator. We paused at a point where, according to the source position, we already are in a class scope, but according to the bytecode (context), we would not yet have created the block context for the class. Also-by: leszeks@chromium.org, jarin@chromium.org Fixed: chromium:1259878 Change-Id: I58b84f4dcfa8c4f51e16812c7a8caa21da99f262 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3284887Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#77940}
-
- 15 Nov, 2021 1 commit
-
-
Leszek Swirski authored
Posting compile tasks from the parser has several issues: 1. We don't know how many functions there will be total, so we can't yet allocate shared_function_infos array on the Script 2. Without this array, inner function compiles can't look up their own inner functions during bytecode finalization, so we can't run that finalization before script parse completes 3. Scope analysis can't have run yet, so we can only post top-level function tasks and if we allocate SharedFunctionInfos early they are forced into a bit of a limbo state without an outer ScopeInfo. Instead, we can post compile tasks during bytecode generation. Then, the script parse is guaranteed to have completed, so we'll have a shared_function_infos array and we will have allocated ScopeInfos already. This also opens the door for posting tasks for compiling more inner functions than just top-level, as well as generating better code for functions/methods that reference same-script top-level let/const/class. Bug: chromium:1267680 Change-Id: Ie1a3a3c6f1b264c4ef28cd4763bfc6dc08f45d4d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277884 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#77894}
-
- 09 Nov, 2021 1 commit
-
-
Joyee Cheung authored
In assignments the lhs should be evaluated first and shouldn't be re-evaluated when the value of the rhs is available. Fix it by saving the receiver and the key registers into AssignmentLhsData before building the assignment and use them later, instead of visiting the AST again to retrieve the receiver. In addition, now that we save the receiver register, use it to perform the brand check even when we know for sure that it's going to fail later because it's a write to a private method or accessing the accessor in the wrong way (v8:11364), so that the brand check error always appears first if it is present, as specified in https://tc39.es/proposal-private-methods/#sec-privatefieldget Drive-by: unify the brand check error messages, and replace "Object" with "Receiver" in the messages for clarity. The instance private brand check now throws "Receiver must be an instance of class <name>" and the static private brand check now throws "Receiver must be class <name>". Also always set the expression position to the property load position, because the brand check failure comes from the load operation. Bug: v8:12352, v8:11364 Change-Id: I61a8979b2e02b561dd5b2b35f9e0b6691fe07599 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3266964 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#77797}
-
- 02 Nov, 2021 1 commit
-
-
Joyee Cheung authored
This improves the performance of initializing instances with private methods by 5-6x and makes it on par with initializing instances with only public methods. Drive-by: remove the obsolete AddPrivateField runtime function along with the AddPrivateBrand function. Bug: v8:10793, v8:12355 Change-Id: Ic0896adb2102db7790f955fecbdd22f61ab2e7ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256999 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#77664}
-
- 18 Oct, 2021 1 commit
-
-
Shu-yu Guo authored
[1] fixes the behavior of StaNamedOwnProperty to no longer do prototype lookups. This lets us revert [2] and go back to using the fast path in the clone spread object literal bytecode. The test case from [2] is kept. [1] https://chromium-review.googlesource.com/c/v8/v8/+/2795831 [2] https://chromium-review.googlesource.com/c/v8/v8/+/3178969 Bug: v8:9888, chromium:1251366 Change-Id: I9d2cb69b803c403f63365f55d27c4de20ff7dafb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3224666Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Patrick Thier <pthier@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#77444}
-
- 13 Oct, 2021 1 commit
-
-
Joyee Cheung authored
Introduces several new runtime mechanics for defining private fields, including: - Bytecode StaKeyedPropertyAsDefine - Builtins StoreOwnIC{Trampoline|Baseline|_NoFeedback} - Builtins KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic} - TurboFan IR opcode JSDefineProperty These new operations can reduce a runtime call per class field into a more traditional Store equivalent. In the microbenchmarks, this results in a substantial win over the status quo (~8x benchmark score for single fields with the changes, ~20x with multiple fields). The TurboFan JSDefineProperty op is lowered in JSNativeContextSpecialization, however this required some hacks. Because private fields are defined as DONT_ENUM when added to the object, we can't find a suitable transition using the typical data property (NONE) flags. I've added a mechanism to specify the required PropertyAttributes for the transition we want to look up. Details: New bytecodes: - StaKeyedPropertyAsDefine, which is essentially StaKeyedProperty but with a different IC builtin (KeyedDefineOwnIC). This is a bytecode rather than a flag for the existing StaKeyedProperty in order to avoid impacting typical keyed stores in any way due to additional branching and testing. New builtins: - StoreOwnIC{TTrampoline|Baseline|_NoFeedback} is now used for StaNamedOwnProperty. Unlike the regular StoreIC, this variant will no longer look up the property name in the prototype. In adddition, this CL changes an assumption that StoreNamedOwnProperty can't result in a map transition, as we can't rely on the property already being present in the Map due to an object literal boilerplate. In the context of class features, this replaces the runtime function %CreateDataProperty(). - KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic} is used by the new StaKeyedPropertyAsDefine bytecode. This is similar to an ordinary KeyedStoreIC, but will not check the prototype for setters, and for private fields, will take the slow path if the field already exists. In the context of class features, this replaces the runtime function %AddPrivateField(). TurboFan IR: - JSDefineProperty is introduced to represent a situation where we need to use "Define" semantics, in particular, it codifies that we do not consult the prototype chain, and the semantics relating to private fields are implied as well. R=leszeks@chromium.org, syg@chromium.org, rmcilroy@chromium.org Bug: v8:9888 Change-Id: Idcc947585c0e612f9e8533aa4e2e0f8f0df8875d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2795831Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#77377}
-
- 30 Sep, 2021 1 commit
-
-
Marja Hölttä authored
Bug: v8:12244, v8:12245 Change-Id: I46cc6fca7d4dda82c825ac15c97bba41ec61378a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3183347Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#77166}
-
- 27 Sep, 2021 1 commit
-
-
Patrick Thier authored
When cloning objects using spread and update properties (e.g. obj = {...o, x: 0}), we wrongly used the setter for the update argument if one was set. This CL changes the behaviour such that all arguments following the spread are treated as dynamic arguments. Bug: chromium:1251366 Change-Id: I76a6d02606dca0faa0a256f465834d85d3df4f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3178969 Commit-Queue: Patrick Thier <pthier@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#77079}
-
- 27 Aug, 2021 1 commit
-
-
Leszek Swirski authored
StaGlobal didn't write the accumulator, but the baseline implementation assumed that it could preserve the accumulator by taking the return value of the StoreGlobalIC. This almost always worked, except for setters on the global object. Fix this by marking StaGlobal as clobbering the accumulator, same as StaNamedProperty (StaNamedProperty needs to do this anyway to avoid inlined setters from needing to create accumulator-preserving frames; StaGlobal would have needed the same thing if we'd ever inlined setters for it). Also, add a new debug scope, EnsureAccumulatorPreservedScope, to the baseline compiler, which checks if the accumulator value is preserved across non-accumulator-writing bytecodes. This found a (benign) bug with ForInPrepare, so fix that too. Fixed: chromium:1242306 Change-Id: I220b5b1c41010c16ac9f944cbd55d2705c299434 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3122325 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#76525}
-
- 24 Aug, 2021 1 commit
-
-
Dan Elphick authored
This is a reland of d1b27019 Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
-
- 23 Aug, 2021 2 commits
-
-
Dan Elphick authored
This reverts commit d1b27019. Reason for revert: Broke vtune build, tsan build and possibly others Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Bug: v8:11965 Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#76428}
-
Dan Elphick authored
This moves every single class/function out of include/v8.h into a separate header in include/, which v8.h then includes so that externally nothing appears to have changed. Every include of v8.h from inside v8 has been changed to a more fine-grained include. Previously inline functions defined at the bottom of v8.h would call private non-inline functions in the V8 class. Since that class is now in v8-initialization.h and is rarely included (as that would create dependency cycles), this is not possible and so those methods have been moved out of the V8 class into the namespace v8::api_internal. None of the previous files in include/ now #include v8.h, which means if embedders were relying on this transitive dependency then it will give compile failures. v8-inspector.h does depend on v8-scripts.h for the time being to ensure that Chrome continue to compile but that change will be reverted once those transitive #includes in chrome are changed to include it directly. Full design: https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing Bug: v8:11965 Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76424}
-
- 13 Aug, 2021 1 commit
-
-
Nicolò Ribaudo authored
Previously V8 was reusing the error fur duplicate declarations, using the private name for class fields or the class name for class methods as the redeclared identifier. class A { constructor(o) { return o } } class B extends A { #x } class C extends A { #x() {} } let D = (0, class extends A { #x() {} }); new B(new B({})) // Identifier '#x' has already been declared new C(new C({})) // Identifier 'C' has already been declared new D(new D({})) // Identifier '' has already been declared This patch changes it to use error messages that better explain what's happening: new B(new B({})) // Cannot initialize #x twice on the same object new C(new C({})) // Cannot initialize private methods of // class C twice on the same object new D(new D({})) // Cannot initialize private methods of // class anonymous twice on the same object I initially tried to use the same message for both fields and methods, but the problem with that is that when initializing fields we only have access to the field name, while when initializing methods we only have access to the class name (using the "private brand" symbol). However, almost all the error messages are different for private fields and for methods so this shouldn't be a problem. Bug: v8:12042 Change-Id: Iaa50c16e4fa5c0646ad9ef2aa7e65bb649b3fce2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3078362Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Joyee Cheung <joyee@igalia.com> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#76279}
-
- 09 Aug, 2021 2 commits
-
-
Ng Zhi An authored
In gdbbjit's event handler, we return early if code_type is not JIT_CODE. Unfortunately, in all CodeLinePosInfo event, we memset the struct, so code_type is always BYTE_CODE, so no line information was getting saved. Drive-by clean up to aggregate initialize JitCodeEvent. Since the initializer list is empty, all members are value-initialized, and in this case, zero-initialized. Bug: v8:12035 Change-Id: I67df2688f13fafbb0806546568eb2574ac8d5e2e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071909Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#76179}
-
legendecas authored
Excluded keys should not be performed with GetOwnPropertyDescriptor on source object in CopyDataProperties. The key values fetch in CopyDataProperties might be arbitrary kind. It may be smi, string, and symbol. Yet the proxy keys collected by KeyAccumulator are not expected types for numeric keys. Those keys should be converted to expected types. Also updates a typo in comments of BytecodeGenerator::BuildDestructuringObjectAssignment. The elements in rest_runtime_callargs should be [value, ...excluded_properties]. Refs: https://tc39.es/ecma262/#sec-copydataproperties Bug: v8:11532 Change-Id: If71bfedf8272ce8405e8566a016fae66b3007dd9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060275Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#76171}
-
- 01 Jul, 2021 1 commit
-
-
Peter Kasting authored
There are still a few cases remaining that seem more controversial; I'll upload those separately. Bug: chromium:1066980 Change-Id: Iabbaf23f9bbe97781857c0c589f2b3db685dfdc2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2994804 Commit-Queue: Peter Kasting <pkasting@chromium.org> Auto-Submit: Peter Kasting <pkasting@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#75494}
-