RFR: 8292755: Non-default method in interface leads to a stack overflow in JShell

[Vicente Romero]

On Tue, 13 Sep 2022 09:27:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> > question, what about generating enough stub data so that flow can play with the ASTs without failing? I'm worried that we may generate more errors than before for buggy bodies and thus some clients will see a different output
> 
> Yes, there may be some more error generated (if the body is erroneous), but I don't see it as a big problem: the errors are there, and when the user adds the `default` keyword (or removes a wrong keyword), the errors will show anyway. To me, it is not clear that a broken modifier is a problem big enough to stop attributing the body - there are many other problems that we find during the attribution of the method header that will not stop method body attribution. Like:
> 
> ```
> $ cat Test.java 
> public interface Test {
>     default void test(Unknown1 t) {
>         Unknown2 tt;
>     }
> }
> $ javac Test.java 
> Test.java:2: error: cannot find symbol
>     default void test(Unknown1 t) {
>                       ^
>   symbol:   class Unknown1
>   location: interface Test
> Test.java:3: error: cannot find symbol
>         Unknown2 tt;
>         ^
>   symbol:   class Unknown2
>   location: interface Test
> 2 errors
> ```
> 
> I am a bit worried that generating more stub data will lead only to a whack-a-mole trying to cover all corner cases where the stub data are not good enough, while simply letting the attribution proceed should cover the cases as it does for normal methods.

I see your point, totally agree

-------------

PR: https://git.openjdk.org/jdk/pull/10221