CommandLineRunner: "renaming cannot be disabled when ADVANCED_OPTIMIZATIONS is used" is wrong about closure-compiler

[lauraharker]

Code incompatible with the assumptions made by variable or property renaming is likely also incompatible with other advanced optimizations, like method devirtualization and inlining.

I think allowing disabling just renaming in advanced optimziations mode gives a false sense of security that an app will work. Instead it can hit more subtle bugs later on in other optimizations.

(@concavelenz wrote up some thoughts on this recently, so tagging him)

Why do you want to just disable renaming? Is it a problem with optimized code not working, or something else?

[kohlschuetter]

Apart from being able to debug the translated code, I am looking into exposing some methods to third-party JavaScript.

I wonder how not renaming types could break the app. Since the operation is only prevented when invoking
via the CommandLineRunner, I wonder if it should be enforced in the first place.

[lauraharker]

To debug the output code, enable "pseudo renaming" mode with the --debug flag.

To expose methods to 3p JavaScript, either explicitly expose/export those methods (https://developers.google.com/closure/compiler/docs/externs-and-exports) or fall back to SIMPLE optimizations.

I wonder how not renaming types could break the app.

I'm not saying that not renaming types may break the app. Rather, code that doesn't follow Closure Compiler ADVANCED mode assumptions around when it's safe to rename, will almost certainly fail to conform to other ADVANCED mode assumptions.

Part of the confusion may be terminology. The optimizations controlled by this "renaming" flag are two specific variable and property renaming passes, but they aren't the only compiler passses that may rename properties. For example, method devirtualization may transform Button.prototype.setName to JSCompiler_methods_setName, and property flattening may transform my_project.init to my_project$init.

Dead-code elimination and inlining can also cause problems. For example, if you wanted to expose some method Button.prototype.setName for 3p code but don't reference it in your app otherwise, dead-code elimination could delete it.

[kohlschuetter]

That makes sense. Thanks for the clarification, @lauraharker !