bug with side_effects option

[LongTengDao]

Bug report or feature request? Bug report

Uglify version (uglifyjs -V) 3.9.2

JavaScript input

function f () {
/*#__PURE__*/a();
/*#__PURE__*/b();
}

The uglifyjs CLI command executed or minify() options used.

( {
	compress: {
		side_effects: false,
	},
	output: {
		comments: function () { return true; },
	},
} )

JavaScript output or error produced.

function f(){
/* */a()}

There are multi problems in the sample.

1. b() disapeared
2. I can't keep /*#__PURE__*/ even when set side_effects to false, to leave it open to downstream user to make the decision. Currently, I must decide, whether to treeshake the pure calling, or miss the comment and it will never be treeshaked.

Expected output

function f(){/*#__PURE__*/a(),/*#__PURE__*/b()}

[alexlamsl]

There are no bugs:

• b() is eliminated by drop_side_effect_free() here, which is gated by sequences:
  https://github.com/mishoo/UglifyJS2/blob/3766d5c9621f56dc01176670b7d0bd0c7ef0b325/lib/compress.js#L2271-L2276
  as stated in the template text which you read when you file this issue:

  Note: sub-optimal but correct code is not a bug

  Now if you want to gate that line above behind side_effects, I am happy to accept that as an improvement − simply fix up all the failing tests properly, then submit a Pull Request.

• the #__PURE__ part of comments will always be stripped after processing due to potential mis-annotations (see past discussions, e.g. pure annotation - called CallExpression #2331)

[LongTengDao]

@alexlamsl When side_effects is false, the call after /*#__PURE__*/ should not be treated as pure call as doc said, so I can't understand, why there is no bug while non-pure b() is deleted?

[LongTengDao]

And I can't understand the source in fact... Do you mean directly remove the line 2274?

[alexlamsl]

No, I mean something like:

if (compressor.option("side_effects") && seq.length > 0) {
    body = body.drop_side_effect_free(compressor);
}

[LongTengDao]

@fabiosantoscode Hi~ Would you help to fix this? Maybe the same problem in terser will be fixed together? XD

[fabiosantoscode]

That's a pretty sane fix. Out of curiosity @alexlamsl why not gate the whole drop_side_effect_free machinery behind that check?

@LongTengDao the fix should be pretty easy to implement! You already have the literal source code for it :) to be honest I don't really want to support the use case where uglified code is read by anything other than a JavaScript runtime.