Gotcha. Okay that makes sense. At the same time, I can't help but wonder if the idea of retargeting to new params/locals couldn't somehow be baked into the Cloners to force the issue.
On Fri, Sep 11, 2009 at 3:52 PM, Ray Cromwell <[email protected]> wrote: > > That's currently handled by the new inliner, which I'll be dropping > hopefully today after I drop the Flattener/Unflattener and some other stuff. > Basically, each method-call param is assigned to a temp, and for each local > in the target method, a new temp local is created. CloneStatementVisitor is > run on the target with a subclass that looks up params and locals and > replaces them with references to ones in the callsite. Also, > JReturnStatements are replaced by assignment to a local at the callsite in > cases where the return doesn't short-circuit control flow in the method. > (e.g. returns from inside of a loop or an if statement). This of course > generates a lot of unnecessary temps (an extra parameter temp is only truly > needed in cases where assignment to the param occurs), but there is an > intra-procedural copy-propagation/prune pass which cleans all of these up. > -Ray > > > > On Fri, Sep 11, 2009 at 12:19 PM, <[email protected]> wrote: > >> The one thing I don't understand is how you handle locals and params? >> If you clone an expression or statements from one method into another, >> how do you handle the fact that local refs and params target the wrong >> method? >> >> Otherwise LGTM. >> >> >> http://gwt-code-reviews.appspot.com/66802 >> > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
