Stuff on the local methods branch

[Srikanth]

Thanks Jesper, I will look into the patch you have shared.

Also will look into the merge.

Srikanth

On 04/01/20 10:47 pm, Jesper Steen Møller wrote:
> Hi List
>
> I've dug into some of the tougher bugs which seem to come from LambdaToMethod:
>
> JDK-8235239: Javac should allow local methods above the chained constructor call this()/super()
> Fixed that, patch in an earlier mail.
>
> JDK-8234874: NPE with recursive invocation of local method
> This happens because of the var-captures of recursive methods get accumulated alongside those of lambdas.
> This is really hard to do in the same pass as lambda desugaring.
>
> By experimenting with the same situation for an anomymous local function, I found another problem, based on some Symbol ownership assumptions in Lower. I fixed those by monkeypatching the symbols (but I think it can be improved when hoisting the local methods to class level)
>
> JDK-8232931: ClassCastException while compiling local method with new instance creation
> The cause of this problem is the same as JDK-8234874: Mixing local method and lambda handling in one pass. I found a similar problem, with this:
>
> Runnable r = () -> {
>    int get42() {
>      return 42;
>    }
>    System.out.println(get42());
> };
>
> Basically, LambdaToMethod is really hard to understand and reason about from trying to do two things at once (in two passes even, counting the LambdaAnalyzerPreprocessor which shares state with the outer pass).
> Can't we just have a separate pass ("LowerLocalMethods") that takes care of local methods, like the separation between lambdas and inner classes? We should be able to mark if local methods are used during parsing, so we can skip the lowering if not needed.
>
> Oh, and who can merge in the latest from default into the 'local-methods'-branch?
>
> -Jesper
>