Add support for new.target.

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Keith Miller]

ES6 specifies a new expression new.target that is used to get the target of a "new" call, this is analogus to a this for constructors. For example, if someone called "new function Foo() { print(new.target) }" the resulting output would be the same as "print(Foo.toString())".

[Keith Miller]

Created attachment 256992 [details]
Patch

[WebKit Commit Bot]

Attachment 256992 [details] did not pass style-queue:


ERROR: Source/JavaScriptCore/ChangeLog:1:  ChangeLog entry has no bug number  [changelog/bugnumber] [5]
ERROR: Source/JavaScriptCore/parser/Parser.cpp:2918:  Missing space before ( in if(  [whitespace/parens] [5]
Total errors found: 2 in 10 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Keith Miller]

Created attachment 256994 [details]
Patch

Fixed a url issue.

[Yusuke Suzuki]

Comment on attachment 256994 [details]
Patch

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

Looks nice! only few nits.

> Source/JavaScriptCore/parser/Parser.cpp:2929
> +    if (newCount && m_token.m_type == DOT) {

Let's use `match(DOT)`.

> Source/JavaScriptCore/parser/Parser.cpp:2931
> +        const Identifier* ident = m_token.m_data.ident;

Before extracting ident* from m_token, using `if (match(IDENT))` is preferable.

[Saam Barati]

Comment on attachment 256994 [details]
Patch

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

> Source/JavaScriptCore/bytecompiler/NodesCodegen.cpp:190
> +RegisterID* TargetNode::emitBytecode(BytecodeGenerator& generator, RegisterID* dst)

Nit: Can we call this NewTargetNode?

[Keith Miller]

Created attachment 257097 [details]
Patch

Made the changes recommended. Also, improved the error message if the user puts the wrong identifier after "new."

[Keith Miller]

Created attachment 257098 [details]
Patch

Had an extra period in the error message.

[Keith Miller]

Created attachment 257099 [details]
Patch

I realized that if I was going the node to NewTargetNode I should also change the expression generator to newTargetExpr.

[Saam Barati]

Comment on attachment 257099 [details]
Patch

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

> Source/JavaScriptCore/parser/ASTBuilder.h:183
> +    ExpressionNode* newTargetExpr(const JSTokenLocation location)

small nit: We usually try to name things that create AST nodes "createX".
So here, "createNewTargetNode" or "createNewTargetExpression".

[Keith Miller]

Comment on attachment 257099 [details]
Patch

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

>> Source/JavaScriptCore/parser/ASTBuilder.h:183
>> +    ExpressionNode* newTargetExpr(const JSTokenLocation location)
> 
> small nit: We usually try to name things that create AST nodes "createX".
> So here, "createNewTargetNode" or "createNewTargetExpression".

Is there a reason why thisExpr and superExpr don't follow this rule? I named my function "newTargetExpr" since new.target is similar to this but for constructors, so I was trying to emulate those functions.

[Yusuke Suzuki]

Comment on attachment 257099 [details]
Patch

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

>>> Source/JavaScriptCore/parser/ASTBuilder.h:183
>>> +    ExpressionNode* newTargetExpr(const JSTokenLocation location)
>> 
>> small nit: We usually try to name things that create AST nodes "createX".
>> So here, "createNewTargetNode" or "createNewTargetExpression".
> 
> Is there a reason why thisExpr and superExpr don't follow this rule? I named my function "newTargetExpr" since new.target is similar to this but for constructors, so I was trying to emulate those functions.

Ah, I guess they are just overlooked ones. Could you rename them to createThisExpr, createSuperExpr etc. at the same time?

[Keith Miller]

Comment on attachment 257099 [details]
Patch

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

>>>> Source/JavaScriptCore/parser/ASTBuilder.h:183
>>>> +    ExpressionNode* newTargetExpr(const JSTokenLocation location)
>>> 
>>> small nit: We usually try to name things that create AST nodes "createX".
>>> So here, "createNewTargetNode" or "createNewTargetExpression".
>> 
>> Is there a reason why thisExpr and superExpr don't follow this rule? I named my function "newTargetExpr" since new.target is similar to this but for constructors, so I was trying to emulate those functions.
> 
> Ah, I guess they are just overlooked ones. Could you rename them to createThisExpr, createSuperExpr etc. at the same time?

I'm not a huge fan of mixing new code with refactors, in case things get rolled out. I'll throw another patch up with that fix.

[Yusuke Suzuki]

Comment on attachment 257099 [details]
Patch

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

r+

>>>>> Source/JavaScriptCore/parser/ASTBuilder.h:183
>>>>> +    ExpressionNode* newTargetExpr(const JSTokenLocation location)
>>>> 
>>>> small nit: We usually try to name things that create AST nodes "createX".
>>>> So here, "createNewTargetNode" or "createNewTargetExpression".
>>> 
>>> Is there a reason why thisExpr and superExpr don't follow this rule? I named my function "newTargetExpr" since new.target is similar to this but for constructors, so I was trying to emulate those functions.
>> 
>> Ah, I guess they are just overlooked ones. Could you rename them to createThisExpr, createSuperExpr etc. at the same time?
> 
> I'm not a huge fan of mixing new code with refactors, in case things get rolled out. I'll throw another patch up with that fix.

Make sense.

[WebKit Commit Bot]

Comment on attachment 257099 [details]
Patch

Clearing flags on attachment: 257099

Committed r187108: <http://trac.webkit.org/changeset/187108>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Keith Miller]

rdar://problem/21880884