Closure-compiler: Disable variable renaming in SIMPLE_OPTIMIZATIONS

[chadaustin]

I'd like to use Closure as the final dataflow optimization pass for my compiler, but for debuggability I don't want it to rename anything, even locals. (It's okay if they're inlined or optimized away, but the names should stick if possible.) It looks like that's possible in the code by setting the variable renaming policy to not rename, but there is no way to access that setting from the service or command line as far as I can tell.

Would it make sense to add such an option?

[Dominator008]

Generally we are hesitant about adding new command line flags (@MatrixFrog). I feel that this one might be reasonable though. Let's see what other team members say.
https://github.com/google/closure-compiler/blob/master/src/com/google/javascript/jscomp/CommandLineRunner.java#L214-L234
These flags might be helpful?

[ChadKillingsworth]

I'd rather not add a flag for this as it's use case is very limited. It's pretty easy to make a custom build with this functionality. Or use the Java API.

[chadaustin]

Instead of having granular optimization flags like SIMPLE_OPTIMIZATIONS and ADVANCED_OPTIMIZATIONS, why not just expose the underlying passes like LLVM does? In LLVM, -O1 and -O2 are just presets, but the user has complete control over which passes run and when.

[chadaustin]

Also, if I need to fork my own Closure Compiler for these changes, and assuming I'd like to run it as a web service for use in our online playground, where is the code behind https://closure-compiler.appspot.com/compile?

[chadaustin]

(Truly sorry for the comment spam; another thought popped into my head.) @ChadKillingsworth Regarding use cases, at IMVU, with our Emscripten build, we had three build configurations: iteration, debug, and optimized. Iteration builds for designed to be fast (no closure), debug builds were designed to be easy to step through in the debugger (pretty printed, simple dataflow optimizations via closure, slow compilation), and optimized (full property renaming and everything, slow compilation). One pain point was that, in the debug build, closure would rename function arguments, which made it harder (but not impossible) to figure out what was what.

I think it would be great to have all the knobs of Closure Compiler exposed externally, even if they're not documented in --help.

[MatrixFrog]

Instead of having granular optimization flags like SIMPLE_OPTIMIZATIONS and ADVANCED_OPTIMIZATIONS, why not just expose the underlying passes like LLVM does?

I think one of the main reasons we've avoided this is that some combinations of optimizations don't work well. Some optimizations actually _increase_ the code size, but in such a way that a later optimization can do a better job. Which is not to say we'll never add more flags but that gives you an idea of the reasoning.

where is the code behind https://closure-compiler.appspot.com/compile?

I think we tried to open source this a little while ago but were unable to because it relied on a little bit of proprietary internal infrastructure :( Someday we'd like to rewrite it in a way that it can be easily open sourced.

[ChadKillingsworth]

We do actually expose everything - we just require the user to write their own Java wrapper. It adds a cost of entry that prevents exposing huge foot-guns to the masses.

The easier answer is to fork the repo and add the tweak you'd like. With minor changes it's pretty easy to keep the fork in sync with the main repository.

[dimvar]

If you only need this for debugging, then there is a compiler option generatePseudoNames that we can create a flag for.

For production code, we'd still like to keep the simple optimization levels we have now, rather than expose all the passes individually.

FYI, the set of flags for the compiler internally at Google exposes most passes, and we've seen that it's not a great idea to do that. The user shouldn't be trying out gazillions of combinations to see what works best; they should be able to configure the compiler easily.

[dimvar]

Actually, you can use --debug to generate the pseudo names, so we don't need a new flag for that.