JSClosureCompilerWrapper: setInlineProperties(false)
Fixes an issue where public member variables that are only set in MXML may be incorrectly detected as constants and inlined in release builds. Determined that this happens rarely, so it will have virtually no impact on output file size and will fix really hard to debug issues.
diff --git a/compiler-jx/src/main/java/org/apache/royale/compiler/utils/JSClosureCompilerWrapper.java b/compiler-jx/src/main/java/org/apache/royale/compiler/utils/JSClosureCompilerWrapper.java
index a343d35..638317e 100644
--- a/compiler-jx/src/main/java/org/apache/royale/compiler/utils/JSClosureCompilerWrapper.java
+++ b/compiler-jx/src/main/java/org/apache/royale/compiler/utils/JSClosureCompilerWrapper.java
@@ -407,7 +407,16 @@
options_.setCrossChunkCodeMotion(true);
options_.setCoalesceVariableNames(true);
options_.setCrossChunkMethodMotion(true);
- options_.setInlineProperties(true);
+ // we cannot guarantee that public member variables (called
+ // "properties" by closure) are constant because they may get
+ // set dynamically by the MXML data interpreter. closure assumes
+ // that a variable is constant if it cannot detect any code that
+ // makes changes, even if it isn't meant to be constant.
+ // in my tests, this kind of inlining happened very rarely, and
+ // there's virtually zero impact to file size by turning it off.
+ // however, there's a big upside to avoiding unexpected inlining
+ // that's very hard to debug. -JT
+ options_.setInlineProperties(false);
options_.setInlineVariables(true);
options_.setSmartNameRemoval(true);
options_.setRemoveDeadCode(true);
