- 16 Aug, 2022 1 commit
-
-
Simon Zünd authored
This CL builds upon https://crrev.com/c/3284887 (and partly reverts it). Class literals are a bit iffy when it comes to source position and debugging. Mainly the debugger assumes the following invariant: When we are paused inside a class scope, then we expect the class's BlockContext to be pushed already. On the other hand, when we are paused outside a class scope in a function, we don't expect to find the class's BlockContext. The problem is that there are cases where we can either pause "inside" or "outside" the class scope. E.g.: * `var x = class {};` will break on `class` which is inside the class scope, so we expect the BlockContext to be pushed * `new class x {};` will break on `new` which is outside the class scope, so we expect the BlockContext to not be pushed yet. The issue with the fix in https://crrev.com/c/3284887 is that it adjusted the break position for the bytecode of class literals to ALWAYS be after the BlockContext is pushed. This breaks the second example above. We need to tighten the fix a bit and only defer the break position if the "current source position" is inside the class's scope. This way we always guarantee that the BlockContext is pushed or not, depending if the source position that corresponds to the break position is inside or outside the class's scope. Note 1: The CL updates a lot of the bytecode expectations. This is because the class literals are often the first statement in the snippet so we don't need to defer the break position. Note 2: We add a mirrored debugger test to the inspector test so the fuzzer can have some more fun. Fixed: chromim:1350842 Change-Id: I9b5a409f77be80db674217a685a3fc9f8a0a71cf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827871Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Kim-Anh Tran <kimanh@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#82473}
-
- 18 Jul, 2022 1 commit
-
-
Liviu Rau authored
- Removed duplication and unnecessary indirection from all suites testcfgs. - Introduced a more comprehensive context to cover both command context and other platform specific concerns. - Propagated above context to TestLoader to allow for test counting command execution on all platforms. - Wrapped original pool with another class to give it a new interface and allow injecting different implementations in the future. - Consolidated progress indicators under a single processor in the pipeline. - Consolidated result retention requirements calculation outside of pipeline chain. - Refactored LoaderProc and got it under tests. - Added some more tests for the standard runner. - Extracted BuildConfig class. Bug: v8:12785 Change-Id: I87be040e91f792a983662bb5a10d55b36a14ea7f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3701595Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Liviu Rau <liviurau@chromium.org> Cr-Commit-Position: refs/heads/main@{#81770}
-
- 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}
-
- 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}
-
- 21 Feb, 2022 2 commits
-
-
Leszek Swirski authored
This reverts commit 9f902b74. Reason for revert: Reverting due to various fuzzing issues (numfuzz issues listed in original CL comments, ochang fuzzer in https://bugs.chromium.org/p/chromium/issues/detail?id=1299418) Original change's description: > [turbofan] Making OSR concurrent > > ... to reduce compilation overhead on the main thread for OSR > > Bug: v8:12161 > Change-Id: I54ca5fa6201405daf92dac9cf51d5de4b46577b3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3369361 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> > Cr-Commit-Position: refs/heads/main@{#79188} Bug: v8:12161 Change-Id: Id6f6086517cd77fb1aa60b20fd03528b8e2ca686 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3477104 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79194}
-
Fanchen Kong authored
... to reduce compilation overhead on the main thread for OSR Bug: v8:12161 Change-Id: I54ca5fa6201405daf92dac9cf51d5de4b46577b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3369361Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Cr-Commit-Position: refs/heads/main@{#79188}
-
- 14 Feb, 2022 1 commit
-
-
Yang Guo authored
R=bmeurer@chromium.org Fixed: chromium:1295387 Change-Id: I64461b7360f904fe5e0163263163db48a1c7c69c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3460404 Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#79065}
-
- 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}
-
- 20 Jan, 2022 1 commit
-
-
Jakob Gruber authored
Bug: v8:12552 Change-Id: I99e4d8e8aeba5460f11e54cc1b2bcaea98a5276d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3400964Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#78698}
-
- 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 1 commit
-
-
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}
-
- 25 Nov, 2021 1 commit
-
-
Liu Yu authored
Change-Id: Ifcc666d4eb5674a57e59f52cb86792e51516dedd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300993 Auto-Submit: Liu yu <liuyu@loongson.cn> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#78082}
-
- 22 Nov, 2021 1 commit
-
-
Leszek Swirski authored
There are cases where DeclareEvalVar can fail to create a variable, in particular when the declaration scope is not extensible. Throw an error in such cases. Fixed: chromium:1145119 Change-Id: I6260f570570c4d7801231bdb5f6724f3734444fd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295348 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78017}
-
- 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}
-
- 08 Nov, 2021 1 commit
-
-
Junliang Yan authored
Change-Id: I452cc4b2a25ce2d00825bf8eea7ac4073310583b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3260149Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/main@{#77764}
-
- 02 Nov, 2021 1 commit
-
-
Yang Guo authored
When materializing a scope object, we previously assumed that we will not have any name collisions. This is not correct e.g. when eval introduces an aliased local variable. This CL resolves this wrong assumption. The test case should not crash. It however fails as there is a bug in how debug-evaluate should resolve variables defined in eval. R=verwaest@chromium.org Fixed: chromium:1240962 Bug: chromium:1264852 Change-Id: I0e41e7905589735e25eff221376d09997ea99117 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250911 Auto-Submit: Yang Guo <yangguo@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#77649}
-
- 11 Oct, 2021 1 commit
-
-
Shu-yu Guo authored
I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/r6yl8pfmf9s/m/ApOmYIuNBgAJ Also adds findLast and findLastIndex to the list of no-side-effect builtins for the debugger. Bug: v8:11990 Change-Id: I285bf499afc2632ffb4e22cf2ea13c978e21e979 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3217757Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#77328}
-
- 16 Aug, 2021 1 commit
-
-
Georg Neis authored
- Remove flag --block-concurrent-recompilation and its implementation, including %UnblockConcurrentCompilation. - Rewrite tests that used it in terms of the primitives introduced in my previous CL: https://chromium-review.googlesource.com/c/v8/v8/+/3071400/ - Remove "sync"/"no sync" arguments from %GetOptimizationStatus, assertOptimized, etc. These are now always "no sync": they don't do any magic. - Remove "if %IsConcurrentRecompilationSupported then quit" from some tests in favor of --concurrent-recompilation in their Flags line. Bug: v8:12041, v8:7790 Change-Id: I966aae4fec85e6f9e7aeed2ba2c12e9198a3991f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3077149Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#76298}
-
- 04 Aug, 2021 1 commit
-
-
Mythri A authored
Add support to flush only baseline code. FLAG_flush_baseline_code controls if baseline code is flushed or not and FLAG_flush_bytecode controls if bytecode is flushed or not. With this CL it is possible to control if we want to flush only bytecode / only baseline code / both. This also lets us have different heuristics for bytecode and baseline code flushing. Bug: v8:11947 Change-Id: Ibdfb9d8be7e7d54196db7890541fa0b5d84f037e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060481Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#76075}
-
- 02 Aug, 2021 1 commit
-
-
Mythri A authored
stress_flush_bytecode controls stress flushing of both bytecode and baseline code. So rename the flag to better reflect its functionality Bug: v8:11947 Change-Id: Ie6c124a476c3a7c6eabd1d75de030ee15fe78e32 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3062567 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#76043}
-
- 08 Jul, 2021 2 commits
-
-
Patrick Thier authored
This is a reland of 819c3ae2 Original change's description: > Reland "Reland "Improve error messages for property access on null/undefined"" > > This is a reland of 8b18c5e6 > > Original change's description: > > Reland "Improve error messages for property access on null/undefined" > > > > This is a reland of 24c626c1 > > > > Original change's description: > > > Improve error messages for property access on null/undefined > > > > > > Only print the property name when accessing null/undefined if we can > > > convert it to a string without causing side effects. > > > If we can't, omit the property name in the error message. > > > This should avoid confusion when the key is an object with toString(). > > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > > > Object]' anymore, which was misleading since the property accessed would > > > be 'a', but we can't evaluate the key without side effects. > > > > > > Bug: v8:11365 > > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#75250} > > > > Bug: v8:11365 > > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599 > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75571} > > Bug: v8:11365 > Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219 > Auto-Submit: Patrick Thier <pthier@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75604} Bug: v8:11365 Change-Id: I002b537144f328ccbbdcd655e26e5dc87c49c6f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013935Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#75645}
-
Leszek Swirski authored
This reverts commit 819c3ae2. Reason for revert: Sorry Patrick, still failing on some layout tests :( https://test-results.appspot.com/data/layout_results/mac-rel/726365/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html Original change's description: > Reland "Reland "Improve error messages for property access on null/undefined"" > > This is a reland of 8b18c5e6 > > Original change's description: > > Reland "Improve error messages for property access on null/undefined" > > > > This is a reland of 24c626c1 > > > > Original change's description: > > > Improve error messages for property access on null/undefined > > > > > > Only print the property name when accessing null/undefined if we can > > > convert it to a string without causing side effects. > > > If we can't, omit the property name in the error message. > > > This should avoid confusion when the key is an object with toString(). > > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > > > Object]' anymore, which was misleading since the property accessed would > > > be 'a', but we can't evaluate the key without side effects. > > > > > > Bug: v8:11365 > > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#75250} > > > > Bug: v8:11365 > > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599 > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75571} > > Bug: v8:11365 > Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219 > Auto-Submit: Patrick Thier <pthier@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75604} Bug: v8:11365 Change-Id: I7d7c0f201288384c2aa38a51418b582a64213ae0 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013352 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#75626}
-
- 07 Jul, 2021 1 commit
-
-
Patrick Thier authored
This is a reland of 8b18c5e6 Original change's description: > Reland "Improve error messages for property access on null/undefined" > > This is a reland of 24c626c1 > > Original change's description: > > Improve error messages for property access on null/undefined > > > > Only print the property name when accessing null/undefined if we can > > convert it to a string without causing side effects. > > If we can't, omit the property name in the error message. > > This should avoid confusion when the key is an object with toString(). > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > > Object]' anymore, which was misleading since the property accessed would > > be 'a', but we can't evaluate the key without side effects. > > > > Bug: v8:11365 > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75250} > > Bug: v8:11365 > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75571} Bug: v8:11365 Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219 Auto-Submit: Patrick Thier <pthier@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#75604}
-
- 06 Jul, 2021 2 commits
-
-
Leszek Swirski authored
This reverts commit 8b18c5e6. Reason for revert: Still failing: https://test-results.appspot.com/data/layout_results/V8_Blink_Linux/12469/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html Original change's description: > Reland "Improve error messages for property access on null/undefined" > > This is a reland of 24c626c1 > > Original change's description: > > Improve error messages for property access on null/undefined > > > > Only print the property name when accessing null/undefined if we can > > convert it to a string without causing side effects. > > If we can't, omit the property name in the error message. > > This should avoid confusion when the key is an object with toString(). > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > > Object]' anymore, which was misleading since the property accessed would > > be 'a', but we can't evaluate the key without side effects. > > > > Bug: v8:11365 > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Patrick Thier <pthier@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75250} > > Bug: v8:11365 > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75571} Bug: v8:11365 Change-Id: Ic4137f0d70fa9b10ca70fa921b98ea7e1499f11b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008217 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#75577}
-
Patrick Thier authored
This is a reland of 24c626c1 Original change's description: > Improve error messages for property access on null/undefined > > Only print the property name when accessing null/undefined if we can > convert it to a string without causing side effects. > If we can't, omit the property name in the error message. > This should avoid confusion when the key is an object with toString(). > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > Object]' anymore, which was misleading since the property accessed would > be 'a', but we can't evaluate the key without side effects. > > Bug: v8:11365 > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75250} Bug: v8:11365 Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#75571}
-
- 21 Jun, 2021 1 commit
-
-
Bill Budge authored
This reverts commit 24c626c1. Reason for revert: Blocks V8 roll into Chromium (changed error messages cause tests to fail): https://ci.chromium.org/p/chromium/builders/try/linux-rel/724109? Original change's description: > Improve error messages for property access on null/undefined > > Only print the property name when accessing null/undefined if we can > convert it to a string without causing side effects. > If we can't, omit the property name in the error message. > This should avoid confusion when the key is an object with toString(). > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object > Object]' anymore, which was misleading since the property accessed would > be 'a', but we can't evaluate the key without side effects. > > Bug: v8:11365 > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75250} Bug: v8:11365 Change-Id: Ic63f34033254f55b3871041633d84ea48586a75d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2977374 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by:
Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#75282}
-
- 18 Jun, 2021 1 commit
-
-
Patrick Thier authored
Only print the property name when accessing null/undefined if we can convert it to a string without causing side effects. If we can't, omit the property name in the error message. This should avoid confusion when the key is an object with toString(). E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object Object]' anymore, which was misleading since the property accessed would be 'a', but we can't evaluate the key without side effects. Bug: v8:11365 Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#75250}
-
- 17 Jun, 2021 1 commit
-
-
Toon Verwaest authored
This isn't used outside of tests, so let's just remove it. Change-Id: I06b7ec11911fd8ebc3bbabcba16d0c2a3fafddab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968413Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#75220}
-
- 11 Jun, 2021 1 commit
-
-
Liu Yu authored
Bug: v8:11421 Change-Id: I1d3f8d3211d06d3e47ffd530715c1dbfbaf79fe8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2954905 Auto-Submit: Liu yu <liuyu@loongson.cn> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Commit-Queue: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn> Cr-Commit-Position: refs/heads/master@{#75093}
-
- 01 Jun, 2021 2 commits
-
-
Camillo Bruni authored
- Add d8.file.read() and d8.file.execute() helpers - Change tools and tests to use new d8.file helper - Unify error throwing in v8::Shell::ReadFile Change-Id: I5ef4cb27f217508a367106f01e872a4059d5e399 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928505 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#74883}
-
Benedikt Meurer authored
In the Chrome DevTools Protocol, the step actions are named StepOut, StepOver, and StepInto, but internally we used StepOut, StepNext, and StepIn instead. This change adjusts the naming to be consistent. Bug: chromium:901814, chromium:1162229 Change-Id: Id3502a1b0a4aadd94734ec3d1fef73c1782fa220 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928510Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74877}
-
- 21 May, 2021 1 commit
-
-
Michael Achenbach authored
This adds a new status file indicator "HEAVY" to mark tests with high resource demands. There will be other tests running in parallel, but only a limited number of other heavy tests. The limit is controlled with a new parameter --max-heavy-tests and defaults to 1. The change also marks a variety of tests as heavy that recently had flaky timeouts. Heavy also implies slow, hence heavy tests are executed at the beginning with a higher timeout like other slow tests. The implementation is encapsulated in the test-processor chain. A new processor buffers heavy tests in a queue and adds buffered tests only if other heavy tests have ended their computation. Bug: v8:5861 Change-Id: I89648ad0030271a3a5af588ecc9c43285b728d6d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2905767 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Liviu Rau <liviurau@chromium.org> Cr-Commit-Position: refs/heads/master@{#74712}
-
- 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}
-
- 10 May, 2021 1 commit
-
-
Benedikt Meurer authored
This changes the names reported in stack traces via the Chrome DevTools protocol to follow the WAT naming convention for functions. This aligns the behavior here with the rest of DevTools (i.e. the disassembly in the Sources panel and the Scope sidebar, as well as the Console REPL) to use one consistent naming scheme. Fixed: chromium:1159307 Doc: http://bit.ly/devtools-wasm-entities Bug: chromium:1162229, chromium:1164241, chromium:1071432 Change-Id: Ibe543f39c775944072073fe5f0959412529aa19b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878734Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#74456}
-
- 29 Apr, 2021 3 commits
-
-
Benedikt Meurer authored
The "Restart frame" feature was implemented as part of LiveEdit and primarily used to support LiveEdit of active functions, but that was previously disabled as part of https://crrev.com/c/2846892 because it's too brittle and causes crashes when using seemingly unrelated features. The "Restart frame" feature was also available as a context menu item separately in the DevTools front-end, but that was also already removed as part of https://crrev.com/c/2854681 earlier. So all uses are gone now. This change works by marking Debugger.restartFrame as deprecated and having it respond with a ServerError all the time. It thus allows us to remove a whole bunch of machinery that was essentially just put in various places to support the restart_fp_ magic. In particular the debugger no longer needs any machine specific builtins now. Bug: chromium:1195927 Change-Id: I1153ba6b00e979620af57dd9f58aa1c035ec4484 Fixed: chromium:1203606 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854750Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#74276}
-
Wenyu Zhao authored
* Will bring them back after TPH supports collection. Bug: v8:11641 Change-Id: Ia170302ccaad9595663cf6bc618e725545a916e5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2858294 Auto-Submit: Wenyu Zhao <wenyu.zhao@anu.edu.au> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#74270}
-
Toon Verwaest authored
While evaluating a class literal the containing function points to Token::CLASS. It may have pushed a context for that class that uses the range of the class scope. So far the class scope had a range that started after the class name or class token in case of anonymous classes. That means the source position of the function frame doesn't point to a position that is included in the active context range. This breaks the debugger because it relies on being able to find the matching parser scope for the active context by looking at the source position. The fix is two-fold: - extend the class scope source range to include Token::CLASS - update ScopeChainRetriever::ContainsPosition to include the start position of class scopes as a valid source position. We can't always include start due to arrow functions that don't have braces. Bug: chromium:1156498 Change-Id: I9ec640c6326289dadcb154bb0a329ca6f8188f8b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857957Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#74268}
-
- 28 Apr, 2021 1 commit
-
-
Benedikt Meurer authored
Previously we'd allow to replace the source of functions that are on the current execution stack under certain conditions, but this has resulted in an endless stream of bugs due to weird edge cases, and so we're now limiting LiveEdit to functions that don't have any activation (including not a suspended generator / async function activation). We might eventually add the ability to LiveEdit functions with activations and have them "upgrade upon next invocation", but that doesn't seem to be an extremely important use case right now. Fixed: chromium:1195927 Change-Id: I87a45ba4d0ddcfbf867bd4e73738d76b2d789e04 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846892 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#74249}
-
- 27 Apr, 2021 1 commit
-
-
Wenyu Zhao authored
* Failed tests that also trigger GCs are not filtered out. They are expected to be fixed when TPH supports real garbage collection. Bug: v8:11641 Change-Id: I30b8bcf48d5e3f32439eeffb39d28ee45db2a21c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2849822Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Wenyu Zhao <wenyu.zhao@anu.edu.au> Cr-Commit-Position: refs/heads/master@{#74212}
-
- 26 Apr, 2021 1 commit
-
-
Patrick Thier authored
Change-Id: I1ddb64331053e969edd81debb69cc06b80c1095f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850635 Commit-Queue: Patrick Thier <pthier@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Auto-Submit: Patrick Thier <pthier@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#74170}
-