Discarding unused function arguments affects function.length, which can lead
to some hard to debug issues. This optimization is now done only in "unsafe
mode".
Fix#121
We only touch properties that are present in an object literal, or which are
assigned to. Example:
x = { foo: 1 };
x.bar = 2;
x["baz"] = 3;
x[cond ? "qwe" : "asd"] = 4;
console.log(x.stuff);
The names "foo", "bar", "baz", "qwe" and "asd" will be mangled, and the
resulting mangled names will be used for the same properties throughout the
code. The "stuff" will not be, since it's just referenced but never
assigned to.
This *will* break most of the code out there, but could work on carefully
written code: do not use eval, do not define methods or properties by
walking an array of names, etc. Also, a comprehensive list of exclusions
needs to be passed, to avoid mangling properties that are standard in
JavaScript, DOM, used in external libraries etc.
It would be nice to have access to the filename of the file that includes the code that causes a JavaScript error. This is especially handy if uglifying multiple files at once.
Only a small change is needed for this to happen as it's already available in the function that throws the error.
`-q 0` (default) use single or double quotes such as to minimize the number of
bytes (prefers double quotes when both will do); this is the previous
behavior.
`-q 1` -- always use single quotes
`-q 2` -- always use double quotes
`-q 3` or just `-q` -- always use the original quotes.
Related codegen option: `quote_style`.
Close#495Close#460
Some `yargs` guru please tell me why `uglifyjs --help` doesn't display the
help string for `-q` / `--quotes`, and why it doesn't output the expected
argument types anymore, like good old `optimist` did.
The correct format of a sourcemap is acquired
from a mozilla source map generator by calling
toJSON on this object. This patch alters the
toString function on mozilla generators to print
the format that is to spec instead of the generator's
internal representation of itself.
Previously it returned the abort node from the alternative branch. This is
not much use as it can be different from the one in the body
branch (i.e. return vs. throw) and can trick us into issues like #591.
Fix#591
`\uFEFF` (ZERO WIDTH NO-BREAK SPACE) is removed when parsing, but was
un-escaped for the output when `ascii_only` was false.
When using
UglifyJS multiple times (creating packages from minified sources, for
example), this would lead to problems because the byte was removed when
parsing for the second time.
NaN and Infinity were replaced in the output generation, instead of
during compression. This could lead to results where `1/0` was inserted
without parens leading to invalid output.
The nodes are replaced in the compression step now, and the output
generation returns their regular names. This should not be a problem,
since they're already only constructed from the original name.
As `maybe_newline()` is only called when `might_need_semicolon` is `true`, the `max_line_len` option has no effect for files without (or with very few) semicolons (like JSON files). A simple for this problem is to use `maybe_newline()` instead of `noop` as the `newline()` function in non-beautify mode.
* Explicitly forbidden multiple catch clauses as SM-specific feature.
* Simplified describing of UglifyJS->Mozilla AST conversion rules.
* Moved alias rules to single place.
* Removed usage of dynamic type bindings in generated code (speed-up).
* Added directives recognition in SM AST.
* Moved semi-standard SM `Property` type to separate handler.
* Added `const` recognition from SM AST.
* Removed redundant `this`-as-identifier recognition.
* Removed redundant rules for abstract SM types.
* Described `CatchClause` using string syntax.
* Added support for semi-standard `range` tuple as location source.
* Added back-conversion support (to be improved).
This happens when SourceMapConsumer does not have a valid position to map the input line and column. This is a change in mozilla/source-map starting from version 0.1.33
Fixes#436
The effect of not mangling it was visible only with --screw-ie8 (otherwise
the names would be mangled exactly because they leaked into the parent
scope).
We can in fact lift sequences, but only if the operation is assignment and
the left-hand side has no side effects nor property access -- that should
guarantee that whatever we place before it cannot affect the sense of the
assignment.
Dropped contrived test case (too hard to support it now), added a more
meaningful one.
The "key" property was always "set" or "get", which didn't make much sense.
Now it'll be the actual name of the setter/getter (AST_Node), and the
AST_Accessor object itself, which represents the function, won't store any
name.
Close#319
Without this fix, the following source:
x = {"\u200c": 42};
would incorrectly be converted into a quoteless key. But while \u200c is allowed
to be in identifiers, it cannot be at the beginning, as per ES5.
(For example, the SockJS client library doesn't work under uglify starting with
d9ad3c7c.)
ev() should do a single thing — evaluate constant expressions. if that's
not possible, just return the original node. it's not the best place for
partial evaluation there, instead doing it in the compress functions.
1529ab96 started to do this (by considering holes to be separate from
"undefined") but it still converted
[1,,] (length 2, last element hole, trailing comma)
to
[1,] (length 1, trailing comma)
Unfortunately the test suite doesn't really make this clear: the new test here
passes with or without this patch because run-tests.js beautifys the expected
output (in "make_code"), which does the incorrect transformation! If you make
some manual change to arrays.js to make the test fail and see the INPUT and
OUTPUT, then you can see that without this fix, [1,,] -> [1,], and with this fix
it stays [1,,].
Since \0 might be mistakenly interpreted as octal if followed by a
number and using literal null is in some cases interpreted as end of
string, escape null as \x00.
Previously:
Without `--screw-ie`, UglifyJS would always leak names of function
expressions into the containing scope, as if they were function
declarations. That was to emulate IE<9 behavior. Code relying on this
IE bug would continue to work properly after mangling, although it would
only work in IE (since other engines don't share the bug). Sometimes
this broke legitimage code (see #153 and #155).
With `--screw-ie` the names would not be leaked into the current scope,
working properly in legit cases; but still it broke legit code when
running in IE<9 (see #24).
Currently:
Regardless of the `--screw-ie` setting, the names will not be leaked.
Code relying on the IE bug will not work properly after mangling.
<evil laughter here>
Without `--screw-ie`: a hack has been added to the mangler to avoid
using the same name for a function expression and some other variable in
the same scope. This keeps legit code working, at the (negligible,
indeed) cost of one more identifier.
With `--screw-ie` you allow the mangler to name function expressions
with the same identifier as another variable in scope. After mangling
code might break in IE<9.
Oh man, the commit message is longer than the patch.
Fix#153, #155
For now the implication is that UglifyJS will not leak a function
expression's name in the surrounding scope (IE < 9 does that).
(ref. mishoo/UglifyJS#485)
It's not safe to transform it to {...} because the body might contain
`break`. The solution could be more elaborate (detect if body contains
`break`) but I don't think it's worth the trouble.
Close#129
1b6bcca7 was a first attempt at this. That commit made Uglify stop replacing
holes with undefined, but instead it started replacing undefined with
holes. This is slightly problematic, because there is a difference between a
hole and an undefined value. More problematically, it changed [1,undefined] to
[1,] which generally doesn't even parse as a hole (just as a trailing comma), so
it didn't even preserve the length of the array!
Instead, parse holes as their own special AST node which prints invisibly.
