add Date and other known globals to unsafe compress option

[kzc]

We missed this one in #2236.

I think Date has been in javascript from the start.

[alexlamsl]

@kzc indeed - how did I miss that?!

Anyway, now that we are here, I wonder if things like parseInt() should be added as well:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects

[kzc]

Sure, we can add parseInt.

What about the following?

setTimeout
setInterval
clearTimeout
clearInterval
JSON

I don't think we should add the various typed Array types, nor should we add Map, Set, WeakMap and WeakSet - in uglify-js at least.

Which of the Error types should we add?

Error
EvalError
InternalError
RangeError
ReferenceError
SyntaxError
TypeError
URIError

[alexlamsl]

Hmm - global (side-effect-free) functions can't be optimised with the current code path, so I'll handle them in a separate PR.

As for the objects, I took the controversial step of testing if those mentioned on MDN exist under IE8:

EvalError
RangeError
ReferenceError
SyntaxError
TypeError
URIError
Date
JSON

[alexlamsl]

And since we have console, may be we should add self as well (window doesn't work within Web Worker)

[kzc]

Your list looks good - I'll update this PR. But I'll leave self out.

$ node0_10_41 -v
v0.10.41

$ node0_10_41 
> EvalError
[Function: EvalError]
> RangeError
[Function: RangeError]
> ReferenceError
[Function: ReferenceError]
> SyntaxError
[Function: SyntaxError]
> TypeError
[Function: TypeError]
> URIError
[Function: URIError]
> Date
[Function: Date]
> JSON
{}
> self
ReferenceError: self is not defined

[alexlamsl]

@kzc good catch & thanks! 😉

[kzc]

global (side-effect-free) functions can't be optimised with the current code path, so I'll handle them in a separate PR.

I thought global_names in lib/compress.js is just a list of known global symbols - unrelated to being side-effect-free:

    var global_names = makePredicate("Array Boolean console Error Function Math Number RegExp Object String");
    AST_SymbolRef.DEFMETHOD("is_declared", function(compressor) {
        return !this.definition().undeclared
            || compressor.option("unsafe") && global_names(this.name);
    });

Are you sure you don't want the following included in global_names as well?

setTimeout
setInterval
clearTimeout
clearInterval

[alexlamsl]

I'm referring to the fact that adding say parseInt to global_names alone won't make the common use case of parseInt(a) go away, as demonstrated by console:

$ echo 'console' | uglifyjs -c
console;

$ echo 'console' | uglifyjs -c unsafe


$ echo 'console()' | uglifyjs -c unsafe
console();

But I see your point about setTimeout without any function invocation being safe to be eliminated - same methodology as #2302 (comment) reveals:

eval
isFinite
isNaN
parseFloat
parseInt
decodeURI
decodeURIComponent
encodeURI
encodeURIComponent
escape
unescape

Further in https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope:

clearInterval
clearTimeout
setInterval
setTimeout

[kzc]

adding say parseInt to global_names alone won't make the common use case of parseInt(a) go away, as demonstrated by console

Indeed, I was aware of that. I see - you wanted an additional optimization for the pure call case.

I will incorporate your new list.

Any consequences to adding eval? It should be safe in the context of global_names I suppose.

[alexlamsl]

Any consequences to adding eval? It should be safe in the context of global_names I suppose.

Removing say var fn = eval; completely when fn is unused should be safe AFAICT.

[kzc]

There's a problem testing the following the test sandbox:

clearInterval;
clearTimeout;
setInterval;
setTimeout;

Those symbols do not exist.

Do we include them in global_names with no corresponding test? Or simply leave them out altogether from lib/compress.js?

[alexlamsl]

Can we make a separate test case without expect_stdout and include those there?

[kzc]

@alexlamsl Suggestions incorporated. PTAL.

[kzc]

Regarding #2302 (comment) - all these years I thought these functions would throw on bad input...

$ node
> parseInt(null)
NaN
> parseInt("QWERTY123")
NaN
> parseFloat("QWERTY123")
NaN

So they'd make fine pure functions in another PR.

[alexlamsl]

Your latest changes LGTM 👍

Most global functions in ES5 are very tolerant - so far I've only found these exceptions:

Function(1, 2);
RegExp(1, 2);
Array(NaN);