b88c5a8d4f
7 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Joyee Cheung
|
0e07eb5341 |
Reland "[class] implement reparsing of class instance member initializers"
This is a reland of
|
||
|
Joyee Cheung
|
f668e9f7ae |
Revert "[class] implement reparsing of class instance member initializers"
This reverts commit
|
||
|
Joyee Cheung
|
91f08378bc |
[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} |
||
|
Joyee Cheung
|
4e8c62819a |
[class] implement static private methods
This patch refactors the declaration and allocation of the class variable, and implements static private methods: - The class variable is declared in the class scope with an explicit reference through class_scope->class_variable(). Anonymous classes whose class variable may be accessed transitively through static private method access use the dot string as the class name. Whether the class variable is allocated depending on whether it is used. Other references of the class variable in the ClassLiteral AST node and the ClassInfo structure are removed in favor of the reference through the class scope. - Previously the class variable was always (stack- or context-) allocated if the class is named. Now if the class variable is only referenced by name, it's stack allocated. If it's used transitively by access to static private methods, or may be used through eval, it's context allocated. Therefore we now use 1 less context slots in the class context if it's a named class without anyone referencing it by name in inner scopes. - Explicit access to static private methods or potential access to static private methods through eval results in forced context allocation of the class variables. In those cases, we save its index in context locals in the ScopeInfo and deserialize it later, so that we can check that the receiver of static private methods is the class constructor at run time. This flag is recorded as HasSavedClassVariableIndexField in the scope info. - Classes that need the class variable to be saved due to access to static private methods now save a ShouldSaveClassVariableIndexField in the preparse data so that the bits on the variables can be updated during a reparse. In the case of anonymous classes that need the class variables to be saved, we also re-declare the class variable after the reparse since the inner functions are skipped and we need to rely on the preparse data flags to remember declaring it. Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit Bug: v8:8330 Change-Id: Idd07803f47614e97ad202de3b7faa9f71105eac5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781011 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64219} |
||
Yang Guo
|
50b996f2d5 |
Debugger: expose local scope for class member initializer
R=gsathya@chromium.org Change-Id: I892b96d5749066df476ace705f45a801a795c0a0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706060 Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#62806} |
||
|
Joyee Cheung
|
6c3d784c16 |
Rename fields to names or members
Rename variables and flag names so that the classes can be reused by private methods implementation. In particular: Rename "fields" to "members" in the initializer so that we can initialize both fields and private methods/accessors there, for example: instance_fields_initializer -> instance_members_initializer InitializeClassFieldsStatement -> InitializeClassMembersStatement Rename "private field" to "private name" for the private symbols used to implement private fields so that we can use them to store private methods/accessors later as well, for example: private_field_name_var -> private_name_var NewPrivateFieldSymbol -> NewPrivateNameSymbol The follow-on is in https://chromium-review.googlesource.com/c/v8/v8/+/1301018 The design doc is in https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit?usp=sharing Bug: v8:8330 Change-Id: I1cdca8def711da879b6e4d67c5ff0a5a4a36abbe Reviewed-on: https://chromium-review.googlesource.com/c/1312597 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#57289} |
||
Sathya Gunasekaran
|
230dd86ce6 |
[Class] Fix debug scope iteration for class fields
When trying to print the scope information for the class fields initializer function, the debugger asks the parser to parse the class literal as a function literal (to get the scope info) ... which doesn't quite work. Instead of adding support for parsing the class literal, we just short cicruit this parsing step by just returning an empty context. This works fine because initializer function doesn't have any variables in it's local scope. The one caveat is that the objects in the scope above this function (like the global) are now missing. This trade off is possibly fine for now, as adding parsing support for class literal to only produce would be a lot of code for not enough use. As a follow up to this change, the devtools UI needs to be updated to handle this empty context cleanly. Currently, it doesn't show the `this` object if no context exists even if the `this` object is correctly passed to the UI from the backend. Bug: v8:5367, v8:8122 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I52965f26241bbf6abdc988783aa0fc44bb36901f Reviewed-on: https://chromium-review.googlesource.com/c/1274268 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56611} |