enhance evaluate

[alexlamsl]

@kzc hopefully more productive than intentionally breaking test/compress.js 😉

[kzc]

Sure - intentionally is the operative word. Break stuff the old fashioned way.

I don't follow this PR. No new compress option was introduced, so presumably it's intended to be a safe optimization. What does it mean to ignore side effects in a loop/if/switch/case condition? In which situations are they safe to ignore?

[alexlamsl]

Traditionally AST_Node.evaluate() bails out on expressions like x(), 42 or a = 42. But there are various transformations like, e.g

(function(a) {
    switch (1) {
      case a = 1:
        console.log(a);
        break;
      default:
        console.log(2);
        break;
    }
})(1);

which we can optimise the AST without dropping the evaluating expression.

What we want here is to inspect the constant value produced without worrying about any side effects caused by said expression.

[alexlamsl]

So optimisations of this form already exist but it only applies to a, b, 42 − with this PR we can extend to something like a, (b = (c, 42))

[kzc]

inspect the constant value produced without worrying about any side effects caused by said expression

Interesting. That would be a good comment for ignore_side_effects.

So only AST_Assign and AST_Sequence presently support this feature?

[kzc]

I think I get it now - you only use this in conjunction with is_truthy:

                var ev = value.is_truthy() || value.evaluate(compressor, true);

[alexlamsl]

So only AST_Assign and AST_Sequence presently support this feature?

Yes (for now) − only used to support AST_Sequence at the top level, not supports both types within nested expression as well.