Illegal break statement - Compress option removes do statements when while is false. do { ... } while(false)

[volumeone]

In a do-while statement, if while is always false, it will remove the do and while, but leave the code inside the block. That makes sense unless there are break statements left over.

For example: this is a technique to avoid deeply nested IF statements:

do {
  if (some_condition) {
    break;
  }

  if (another_condition) {
    break;
  }

  // Do something here.

} while (false);

Uglify converts that to this:

if (some_condition) {
  break;
}

if (another_condition) {
  break;
}

which causes an "Illegal break statement" error.

The do-while statements should not be removed when they contain break statements.

[mishoo]

That's a good report. I don't have an immediate fix, but just to show you how I write similar code:

OUT: {
  if (some_condition) {
    break OUT;
  }
  if (something_else) {
    break OUT;
  }
  // ... etc.
}

There's no need for the do/while, unless you want to satisfy JSHint, which for some reason thinks the above code is not valid.

[kzc]

@volumeone Unable to reproduce.

$ uglifyjs -V
uglify-js 2.6.2

$ echo 'function f(x,y){do{if(x)break;if(y)break;foo()}while(false)}' | uglifyjs -c
function f(x,y){do{if(x)break;if(y)break;foo()}while(!1)}

Which uglify version and flags are you using?

[volumeone]

Thanks @kzc I was using the wrong NPM package: uglify-js2 which was at version 2.1.11. I installed uglify-js with version 2.6.2 and that's no longer an issue.

[avdg]

Yeah, this issue is a plague :-)

See #936

[christensson]

This still doesn't work on 2.8.4. Perhaps the same as newly opened #1532?

$ echo 'function f(x,y){do{if(x)break;if(y)break;foo()}while(false)}' | node_modules/.bin/uglifyjs -c                                                                                              
function f(x,y){if(x)break;if(y)break;foo()}

$ node_modules/.bin/uglifyjs --version
uglify-js 2.8.4

It works when setting evaluate to false in compress options.

[alexlamsl]

@christensson I think it's a new regression instead of an old bug - please follow/comment on #1532 instead.