Closed Bug 1123906 Opened 6 years ago Closed 6 years ago

Get rid of create() static methods in ParseNode and subclasses

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla38

People

(Reporter: jorendorff, Assigned: jorendorff)

Details

Attachments

(1 file)

because they are dumb
Assignee: nobody → jorendorff
Status: NEW → ASSIGNED
Comment on attachment 8552031 [details] [diff] [review]
Get rid of static create() methods on ParseNode subclasses. Use constructors instead

Review of attachment 8552031 [details] [diff] [review]:
-----------------------------------------------------------------

Yes! We (you ;) )will get the frontend wrangled yet! see comment below.

::: js/src/frontend/FullParseHandler.h
@@ +520,5 @@
>                                ParseNode *catchName, ParseNode *catchGuard, ParseNode *catchBody);
>  
>      inline void setLastFunctionArgumentDefault(ParseNode *funcpn, ParseNode *pn);
> +
> +    ParseNode *newFunctionDefinition() {

The idea of dropping the keyword here is that we trust the compiler to know to inline?

@@ +570,5 @@
>      TokenPos getPosition(ParseNode *pn) {
>          return pn->pn_pos;
>      }
>  
> +    ParseNode *newList(ParseNodeKind kind) {

Is the reason this can't have an op=JSOP_NOP here that ListNode lacks such a constructor? It seems like it should be useful to have that, no? The uses below with create, nullcheck, setOp seem really cumbersome.
Attachment #8552031 - Flags: review?(efaustbmo) → review+
(In reply to Eric Faust [:efaust] from comment #2)
> ::: js/src/frontend/FullParseHandler.h
> > +    ParseNode *newFunctionDefinition() {
> 
> The idea of dropping the keyword here is that we trust the compiler to know
> to inline?

Method definitions inside classes are automatically inline. It's a rule of C++. That is, they automatically have the `inline` qualifier or whatever it is. Whether they are actually inlined is of course up to the compiler, with or without the keyword...

> > +    ParseNode *newList(ParseNodeKind kind) {
> 
> Is the reason this can't have an op=JSOP_NOP here that ListNode lacks such a
> constructor? It seems like it should be useful to have that, no? The uses
> below with create, nullcheck, setOp seem really cumbersome.

Well, I left it ugly on purpose. Cumbersome concepts should look cumbersome in the code...

...but all right, I went and added the extra constructor and fixed up the call sites. No more setOp.

(Doing that, I discovered I had accidentally deleted a null-check in one of the Parser methods. Yow.)
https://hg.mozilla.org/mozilla-central/rev/1f3af5e261d1
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
You need to log in before you can comment on or make changes to this bug.