New patch, and added some hopefully helpful commentary.
http://gwt-code-reviews.appspot.com/1442807/diff/4001/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java File dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java (left): http://gwt-code-reviews.appspot.com/1442807/diff/4001/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java#oldcode519 dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java:519: allRootTypes.add(FragmentLoaderCreator.ASYNC_FRAGMENT_LOADER); This was an indexed type anyway. http://gwt-code-reviews.appspot.com/1442807/diff/4001/dev/core/src/com/google/gwt/dev/jjs/impl/ControlFlowAnalyzer.java File dev/core/src/com/google/gwt/dev/jjs/impl/ControlFlowAnalyzer.java (right): http://gwt-code-reviews.appspot.com/1442807/diff/4001/dev/core/src/com/google/gwt/dev/jjs/impl/ControlFlowAnalyzer.java#newcode92 dev/core/src/com/google/gwt/dev/jjs/impl/ControlFlowAnalyzer.java:92: private JMethod currentMethod; This is needed because the whole stack of methods isn't tracked when dependency recorder isn't running. http://gwt-code-reviews.appspot.com/1442807/diff/4001/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java File dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java (right): http://gwt-code-reviews.appspot.com/1442807/diff/4001/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java#newcode1691 dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java:1691: gwtOnLoad.setArtificiallyRescued(true); This turns out to be a much better signal to JsUnusedFunctionRemover. http://gwt-code-reviews.appspot.com/1442807/diff/4001/dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java File dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java (right): http://gwt-code-reviews.appspot.com/1442807/diff/4001/dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java#newcode86 dev/core/src/com/google/gwt/dev/jjs/impl/JsFunctionClusterer.java:86: return; Some fragments are now so small, they don't contain any functions. :) http://gwt-code-reviews.appspot.com/1442807/diff/4001/dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java File dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java (right): http://gwt-code-reviews.appspot.com/1442807/diff/4001/dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java#newcode677 dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java:677: refType = nullifyArrayType(arrayType); I ran into an oscillation bug here, because in one test, RunAsyncCallback[][] kept getting transformed to null[] and back due to RunAsyncCall[] being uninstantiable. But, we don't modify the corresponding JNewArray that was flowing into this expression. Seems like we should either type-tighten JNewArray, or else not do this at all. But this fixes the immediate bug... possibly by disabling the optimization in all cases. http://gwt-code-reviews.appspot.com/1442807/diff/4001/dev/core/src/com/google/gwt/dev/js/JsUnusedFunctionRemover.java File dev/core/src/com/google/gwt/dev/js/JsUnusedFunctionRemover.java (left): http://gwt-code-reviews.appspot.com/1442807/diff/4001/dev/core/src/com/google/gwt/dev/js/JsUnusedFunctionRemover.java#oldcode118 dev/core/src/com/google/gwt/dev/js/JsUnusedFunctionRemover.java:118: (new JsNameRefVisitor()).accept(program); This was just doing a more work than it needed to. http://gwt-code-reviews.appspot.com/1442807/diff/4001/dev/core/test/com/google/gwt/dev/jjs/impl/RunAsyncNameTest.java File dev/core/test/com/google/gwt/dev/jjs/impl/RunAsyncNameTest.java (left): http://gwt-code-reviews.appspot.com/1442807/diff/4001/dev/core/test/com/google/gwt/dev/jjs/impl/RunAsyncNameTest.java#oldcode64 dev/core/test/com/google/gwt/dev/jjs/impl/RunAsyncNameTest.java:64: builder.expectError("Cannot proceed due to previous errors", null); Because this is now caught by ReplaceRunAsync instead of FindDeferredBindingSitesVisitor. http://gwt-code-reviews.appspot.com/1442807/diff/4001/user/src/com/google/gwt/core/client/GWT.java File user/src/com/google/gwt/core/client/GWT.java (right): http://gwt-code-reviews.appspot.com/1442807/diff/4001/user/src/com/google/gwt/core/client/GWT.java#newcode248 user/src/com/google/gwt/core/client/GWT.java:248: callback.onSuccess(); What I have done here is make it so that the code simply behaves as if the target fragment were already loaded. I don't think the stats events (that don't match real splitting anyway) are at all important. And there's no need to trap exceptions with the UEH either, if the caller doesn't catch the exception, the UEH will get it eventually anyway. http://gwt-code-reviews.appspot.com/1442807/diff/4001/user/src/com/google/gwt/core/client/impl/AsyncFragmentLoader.java File user/src/com/google/gwt/core/client/impl/AsyncFragmentLoader.java (right): http://gwt-code-reviews.appspot.com/1442807/diff/4001/user/src/com/google/gwt/core/client/impl/AsyncFragmentLoader.java#newcode583 user/src/com/google/gwt/core/client/impl/AsyncFragmentLoader.java:583: } Essentially, the above code used to be generated into each fragment loader. http://gwt-code-reviews.appspot.com/1442807/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
