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())".
Created attachment 256992 [details] Patch
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.
Created attachment 256994 [details] Patch Fixed a url issue.
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.
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?
Created attachment 257097 [details] Patch Made the changes recommended. Also, improved the error message if the user puts the wrong identifier after "new."
Created attachment 257098 [details] Patch Had an extra period in the error message.
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.
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".
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.
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?
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.
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.
Comment on attachment 257099 [details] Patch Clearing flags on attachment: 257099 Committed r187108: <http://trac.webkit.org/changeset/187108>
All reviewed patches have been landed. Closing bug.
rdar://problem/21880884