Stuff on the local methods branch

[Jesper Steen Møller]

Whoops, mail-client mishap.

-Jesper

> On 7 Jan 2020, at 00.39, Jesper Steen Møller <jesper at selskabet.org> wrote:
> 
> Hi Maurizio
> 
> On 7 Jan 2020, at 00.24, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>> I agree that LambdaToMethod was already complicated to begin with and now it gotten worse (I'm guilty of that, as I wrote the first hacky patch). Splitting local methods into their own phase seems like a good idea - initially I went for LambdaToMethod because this was a quick and dirty experiment and I wanted to reuse as much code as possible. That said, if we do split into a separate phase, we should try not to reinvent solution for problems we have already solved (e.g. find the set of captured entities). And my fear is that you need a lot of what the analyzer preprocessor currently do; I'd be happy to be proven wrong - if not, we could always find other ways to reuse the preprocessing info from multiple stages.
> 
> I suppose I could refactor the “instanced”-style checks into abstract methods on the Context parts, but that will only solve part of the problem: Just like Lambda captures and lambda creation interleaves and need separate passes, so do local method captures and (recursive) local method calls. So it’s not really possible to do in two passes, but need something a separate pass for finding captures and then a separate one for the calls, or we’ll need a work-list or fixed-point type algorithm to deal with all the propagation.
> It’s just simpler to do in separate passes.
> 
> I can try to put together a refactoring patch which adds one more pass for analysis and a separate one for but keeps the same 'Context' structure, or I can try to factor out the context-part and introduce a LocalLower pass altogether.
> 
> Which style would you prefer?
> 
> Oh, and who'll merge in the latest updates from default into the 'local-methods'-branch?
> 
> -Jesper