[Webkit-unassigned] [Bug 194095] [JSC] Add support for static public class fields

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon May 25 08:56:32 PDT 2020


https://bugs.webkit.org/show_bug.cgi?id=194095

Caio Lima <ticaiolima at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ticaiolima at gmail.com

--- Comment #3 from Caio Lima <ticaiolima at gmail.com> ---
Comment on attachment 400054
  --> https://bugs.webkit.org/attachment.cgi?id=400054
Add support for static public fields

View in context: https://bugs.webkit.org/attachment.cgi?id=400054&action=review

I think it is necesssary to have some stress test cases included in this patch, since most of our bots don't run Test262. It is also important to have a test case asserting that the case listed on https://bugs.webkit.org/show_bug.cgi?id=209675 can pass.

> Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp:796
> +    generator.emitJumpIfFalse(generator.emitBinaryOp<OpEq>(generator.newTemporary(), generator.emitLoad(nullptr, JSValue(generator.addStringConstant(generator.propertyNames().prototype))), propertyName, OperandTypes(ResultType::stringType(), ResultType::stringType())), validPropertyNameLabel.get());

I personally think this is very hard to read. Also, I'm not 100% sure if this quite safe if we don't use `RefPtr<>`. Do you mind making it something like:

```
RefPtr<RegisterID> prototypeString = generator.emitLoad(nullptr, generator.propertyNames().prototype);
RefPtr<RegisterID> isValidPropertyName = generator.emitBinaryOp<OpEq>(generator.newTemporary(), prototypeString, propertyName, OperandTypes(ResultType::stringType(), ResultType::stringType()))
generator.emitJumpIfFalse(isValidPropertyName, validPropertyNameLabel.get());
```

> Source/JavaScriptCore/parser/ASTBuilder.h:408
> +    DefineFieldNode* createDefineField(const JSTokenLocation& location, const Identifier* ident, ExpressionNode* initializer, DefineFieldNode::Type type, bool isStatic)

Could you turn `bool isStatic` into an enum?

> Source/JavaScriptCore/parser/Nodes.h:2295
> +        DefineFieldNode(const JSTokenLocation&, const Identifier*, ExpressionNode*, Type, bool);

Ditto

> Source/JavaScriptCore/parser/Parser.cpp:259
>          else if (parseMode == SourceParseMode::InstanceFieldInitializerMode) {

This is not accurate anymore, since it is also being used for static fields. I think I would prefer create a new `SourceParseMode::StaticFieldInitializerMode` with reason described bellow.

> Source/JavaScriptCore/parser/Parser.cpp:2872
> +    unsigned numInstanceComputedFields = 0, numStaticComputedFields = 1;

I think that a comment here to explain why `numStaticComputedFields` starts with 1 would help a lot. Also, WDYT if we call them as `nextInstanceComputedFieldID` and `nextStaticComputedFieldID`?

> Source/JavaScriptCore/parser/Parser.cpp:2978
> +                unsigned* fieldID = tag == ClassElementTag::Instance ? &numInstanceComputedFields : &numStaticComputedFields;

I'm also in favor of using:

```
if (tag == ClassElementTag::Instance)
    ident = &m_parserArena.identifierArena().makeNumericIdentifier(m_vm, nextInstanceComputedFieldID++);
else
    ident = &m_parserArena.identifierArena().makeNumericIdentifier(m_vm, nextStaticComputedFieldID++);
```

> Source/JavaScriptCore/parser/Parser.cpp:3047
> +template <class TreeBuilder> TreeSourceElements Parser<LexerType>::parseInstanceFieldInitializerSourceElements(TreeBuilder& context, const Vector<JSTextPosition>& classFieldLocations)

This function is also being used to initialize static fields. I think we should rename it to `parseFieldInitializerSourceElements`.

> Source/JavaScriptCore/parser/Parser.cpp:3053
> +    // fields, at 1 for static fields. We'll bump the counter by one

Instead of having this check down there, we could use the `parseMode` to properly initialize `numComputedFields`. I would also rename it as `nextComputedFieldID`.

> Source/JavaScriptCore/runtime/JSFunction.cpp:-759
> -    ASSERT(jsExecutable()->ecmaName().isNull());

Is there a reason to remove this ASSERT?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200525/610902d8/attachment-0001.htm>


More information about the webkit-unassigned mailing list