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 -~----------~----~----~----~------~----~------~--~---
