if undefined is defined, ;-), we replace AST_Undefined nodes to a reference
to the "undefined" variable; in turn the mangler will compress it to a
single letter; this helps at least on jQuery.
- a = a + x ==> a+=x
- joining consecutive var statements (hoisting is not always desirable)
- x == false ==> x == 0, x != true ==> x != 1
- x, x ==> x; x = exp(), x ==> x = exp()
- discarding useless break-s
- do multiple passes in tighten_body if it was changed
- transform if (foo) return x; return y; ==> return foo?x:y
- don't optimize !0 as true (use best_of after evaluation of constant expr)
With hoist_vars off we now beat UglifyJS v1 on jQuery-1.8.1
- all symbols now have a `thedef` property which is a SymbolDef object,
instead of the `uniq` that we had before (pointing to the first occurrence
of the name as declaration).
- for undeclared symbols we still create a SymbolDef object in the toplevel
scope but mark it "undeclared"
- we can now call figure_out_scope after squeezing, which is useful in order
not to mangle names that were dropped by the squeezer
The following nodes were instances of AST_BlockStatement: AST_Scope,
AST_SwitchBlock, AST_SwitchBranch. Also, AST_Try, AST_Catch, AST_Finally
were having a body instanceof AST_BlockStatement.
Overloading the meaning of AST_BlockStatement this way turned out to be a
mess; we now have an AST_Block class that is the base class for things
having a block of statements (might or might not be bracketed). The
`this.body` of AST_Scope, AST_Try, AST_Catch, AST_Finally is now an array of
statements (as they inherit from AST_Block).
Avoiding calling superclass's _walk function in walkers (turns out we walked
a node multiple times).
optimize away while(false), and transform while(true) ==> for(;;).
UNSAFE:
some expressions are optimized away when we're in boolean context and can
determine that the value will always be true or false. For example:
x() || true ==> always `true` in boolean context
x() && false ==> always `false` in boolean context
It's not technically correct to drop these expressions since we drop the
function call too (that might have side effects); on the other hand, I can't
see any legitimate use for such expressions and they might simply indicate a
bug (we do warn about it).
