Skip to content

tweak do-while loops#1452

Closed
alexlamsl wants to merge 1 commit intomishoo:masterfrom
alexlamsl:loops
Closed

tweak do-while loops#1452
alexlamsl wants to merge 1 commit intomishoo:masterfrom
alexlamsl:loops

Conversation

@alexlamsl
Copy link
Copy Markdown
Collaborator

Much more straightforward than #1451 - just adding do{...}while(false) and consolidating AST_While optimisations.

@alexlamsl
Copy link
Copy Markdown
Collaborator Author

Previously optimising AST_While calls the whole code block from AST_DWLoop. Might as well just move these few lines into AST_DWLoop instead.

AST_While is being directly substituted by a AST_For. if_break_in_loop() will be called within AST_For so no need to duplicate the efforts.

extract_declarations_from_unreachable_code(compressor, self.body, a);
return make_node(AST_BlockStatement, self, { body: a });
}
} else {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add comment: // self instanceof AST_Do

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

if (!compressor.option("loops")) return self;
self = AST_DWLoop.prototype.optimize.call(self, compressor);
if (self instanceof AST_While) {
if_break_in_loop(self, compressor);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the equivalent logic for if_break_in_loop(self, compressor); in the new OPT(AST_DWLoop) code above? I see a newly added else clause for the self instanceof AST_Do case, but the AST_While logic is the same as it was. Was if_break_in_loop never needed?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AST_For does if_break_in_loop() already, so once AST_While is turned into AST_for and .transform(compressor), it should be covered.

It is technically not calling if_break_in_loop() in the same order (or even the same number of times) as before, but I had a scan through the method and thinks this is safe to do if not a minor performance improvement.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Thanks.

lib/compress.js Outdated
return make_node(AST_BlockStatement, self, { body: a });
}
} else {
} else { // self instanceof AST_Do
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ugh - comment after a brace! I'll get over it.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could do } else /*if (self instanceof AST_Do)*/ { if that pleases the gods... 😉

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gosh, no. On its own line please:

} else {
    // self instanceof AST_Do
    ...

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@kzc
Copy link
Copy Markdown
Contributor

kzc commented Feb 1, 2017

LGTM. Ready to squash commits.

- `do{...}while(false)` => `{...}`
- clean up `AST_While` logic
alexlamsl added a commit to alexlamsl/UglifyJS that referenced this pull request Feb 18, 2017
- `do{...}while(false)` => `{...}`
- clean up `AST_While` logic

closes mishoo#1452
@alexlamsl alexlamsl closed this in ae4db00 Feb 23, 2017
@alexlamsl alexlamsl deleted the loops branch February 24, 2017 00:19
@kzc
Copy link
Copy Markdown
Contributor

kzc commented Mar 2, 2017

@alexlamsl In light of #1532 can we revert this PR?

I don't have confidence in break analysis in both while(){} and do{}while() loops.

See: #1452 (comment)

@alexlamsl
Copy link
Copy Markdown
Collaborator Author

alexlamsl commented Mar 2, 2017

Just sat down at my desk - let me have a look and see if it's fixable.

If not, I think only the top half of the PR needs to be reverted anyway. Either case I'll come up with a new PR with those test cases from #1532.

}
} else {
// self instanceof AST_Do
return self.body;
Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kzc this is the line which I believe is causing #1532 instead of the section below.

Copy link
Copy Markdown
Contributor

@kzc kzc Mar 2, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return self; would certainly fix the do-while case in #1532. I've already confirmed this.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I am not certain about the handling of breaks and continues in while(){} loops with this PR. There's insufficient test case coverage.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll get rid of this and add new test cases to address #1532. Then we can revisit this optimisation at a later date.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants